Patchwork [v3,5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

login
register
mail settings
Submitter Blue Swirl
Date Sept. 17, 2011, 9:40 p.m.
Message ID <CAAu8pHsSP-NwrsXHub=m-deLgTcrCzR6P3s=KTJw5eT4uXk_Zg@mail.gmail.com>
Download mbox | patch
Permalink /patch/115172/
State New
Headers show

Comments

Blue Swirl - Sept. 17, 2011, 9:40 p.m.
On Thu, Sep 15, 2011 at 11:31 AM, Avi Kivity <avi@redhat.com> wrote:
> On 09/15/2011 01:01 PM, Benjamin Herrenschmidt wrote:
>>
>> >  Sure :). So the problem is that when emulating the G3 Beige machine in
>> >  QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently,
>> >  on x86 that PCI VGA adapter can map the special VGA regions to
>> >  somewhere, namely 0xa0000. With the memory api overhaul, this also
>> >  slipped into the PPC world where mapping 0xa0000 with VGA adapters is
>> >  a pretty bad idea, as it's occupied by RAM.
>> >
>> >  Now the discussion was on which level that mapping would happen and
>> >  which devices go through which buses which then would filter certain
>> >  ranges from being mapped. Basically, which way does a memory request
>> >  from the CPU go on a G3 Beige machine until it arrives the VGA
>> >  adapter?
>> >
>> >  I hope that concludes the actual question. Avi, if I explained this
>> >  wrong, please correct me.
>>
>> Ok so there's several things here.
>>
>> First, the mapping from CPU addresses to PCI addresses. This depends on
>> the host bridge chip. The MPC106, used in the Beige G3, itself supports
>> different type of mappings.
>>
>>  From memory, the way it's configured in a G3 is to have a 1:1 mapping of
>> 80000000 CPU to 80000000 PCI.
>>
>> That means that with this basic mapping, you cannot generate memory
>> accesses to low PCI addresses such as 0xa0000.
>
> Alex, what this means (I think is) that: pci_grackle_init() needs to create
> a container memory region and pass it to pc_register_bus() as the pci
> address space, and create and alias starting at 0x80000000 of the pci
> address space, and map that alias at address 0x80000000 of the system
> address space.
>
> See pc_init1() creating pci_memory and passing it to i440fx_init(), which
> then maps some aliases into the system address space and also gives it to
> pci_bus_new().  It's essentially the same thing with different details.

I think the attached patch (on top of ppc-next) should do it, but it
doesn't. Only the top area of the screen is shown, the rest is black.

>> I don't remember (but it's possible) if it has another region which maps
>> some other (high address) part of the address space down to 0 PCI.
>> Typically that would be a smaller region which specifically allow access
>> to the "ISA hole" that way.
>
> That would be done by mapping yet another alias.
>
> --
> error compiling committee.c: too many arguments to function
>
>
Avi Kivity - Sept. 18, 2011, 11:28 a.m.
On 09/18/2011 12:40 AM, Blue Swirl wrote:
> On Thu, Sep 15, 2011 at 11:31 AM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 09/15/2011 01:01 PM, Benjamin Herrenschmidt wrote:
> >>
> >>  >    Sure :). So the problem is that when emulating the G3 Beige machine in
> >>  >    QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently,
> >>  >    on x86 that PCI VGA adapter can map the special VGA regions to
> >>  >    somewhere, namely 0xa0000. With the memory api overhaul, this also
> >>  >    slipped into the PPC world where mapping 0xa0000 with VGA adapters is
> >>  >    a pretty bad idea, as it's occupied by RAM.
> >>  >
> >>  >    Now the discussion was on which level that mapping would happen and
> >>  >    which devices go through which buses which then would filter certain
> >>  >    ranges from being mapped. Basically, which way does a memory request
> >>  >    from the CPU go on a G3 Beige machine until it arrives the VGA
> >>  >    adapter?
> >>  >
> >>  >    I hope that concludes the actual question. Avi, if I explained this
> >>  >    wrong, please correct me.
> >>
> >>  Ok so there's several things here.
> >>
> >>  First, the mapping from CPU addresses to PCI addresses. This depends on
> >>  the host bridge chip. The MPC106, used in the Beige G3, itself supports
> >>  different type of mappings.
> >>
> >>    From memory, the way it's configured in a G3 is to have a 1:1 mapping of
> >>  80000000 CPU to 80000000 PCI.
> >>
> >>  That means that with this basic mapping, you cannot generate memory
> >>  accesses to low PCI addresses such as 0xa0000.
> >
> >  Alex, what this means (I think is) that: pci_grackle_init() needs to create
> >  a container memory region and pass it to pc_register_bus() as the pci
> >  address space, and create and alias starting at 0x80000000 of the pci
> >  address space, and map that alias at address 0x80000000 of the system
> >  address space.
> >
> >  See pc_init1() creating pci_memory and passing it to i440fx_init(), which
> >  then maps some aliases into the system address space and also gives it to
> >  pci_bus_new().  It's essentially the same thing with different details.
>
> I think the attached patch (on top of ppc-next) should do it, but it
> doesn't. Only the top area of the screen is shown, the rest is black.

I can't see anything wrong with the patch either.
Alexander Graf - Sept. 19, 2011, 9:15 a.m.
On 17.09.2011, at 23:40, Blue Swirl wrote:

> On Thu, Sep 15, 2011 at 11:31 AM, Avi Kivity <avi@redhat.com> wrote:
>> On 09/15/2011 01:01 PM, Benjamin Herrenschmidt wrote:
>>> 
>>>>  Sure :). So the problem is that when emulating the G3 Beige machine in
>>>>  QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently,
>>>>  on x86 that PCI VGA adapter can map the special VGA regions to
>>>>  somewhere, namely 0xa0000. With the memory api overhaul, this also
>>>>  slipped into the PPC world where mapping 0xa0000 with VGA adapters is
>>>>  a pretty bad idea, as it's occupied by RAM.
>>>> 
>>>>  Now the discussion was on which level that mapping would happen and
>>>>  which devices go through which buses which then would filter certain
>>>>  ranges from being mapped. Basically, which way does a memory request
>>>>  from the CPU go on a G3 Beige machine until it arrives the VGA
>>>>  adapter?
>>>> 
>>>>  I hope that concludes the actual question. Avi, if I explained this
>>>>  wrong, please correct me.
>>> 
>>> Ok so there's several things here.
>>> 
>>> First, the mapping from CPU addresses to PCI addresses. This depends on
>>> the host bridge chip. The MPC106, used in the Beige G3, itself supports
>>> different type of mappings.
>>> 
>>>  From memory, the way it's configured in a G3 is to have a 1:1 mapping of
>>> 80000000 CPU to 80000000 PCI.
>>> 
>>> That means that with this basic mapping, you cannot generate memory
>>> accesses to low PCI addresses such as 0xa0000.
>> 
>> Alex, what this means (I think is) that: pci_grackle_init() needs to create
>> a container memory region and pass it to pc_register_bus() as the pci
>> address space, and create and alias starting at 0x80000000 of the pci
>> address space, and map that alias at address 0x80000000 of the system
>> address space.
>> 
>> See pc_init1() creating pci_memory and passing it to i440fx_init(), which
>> then maps some aliases into the system address space and also gives it to
>> pci_bus_new().  It's essentially the same thing with different details.
> 
> I think the attached patch (on top of ppc-next) should do it, but it
> doesn't. Only the top area of the screen is shown, the rest is black.

Without your patch:

(qemu) info mtree 
memory
00000000-fffffffe : system
  800a0000-800affff : vga.chain4
  80880000-808fffff : macio
    00060000-0007ffff : macio-nvram
    00020000-00020fff : pmac-ide
    00016000-00017fff : cuda
    00013000-0001303f : escc-bar
    00008000-00008fff : dbdma
    00000000-00000fff : heathrow-pic
  80800000-8080ffff : vga.rom
  80000000-807fffff : vga.vram
  800a0000-800bffff : vga-lowmem
  80013000-8001303f : escc
  fee00000-fee00fff : pci-data-idx
  fec00000-fec00fff : pci-conf-idx
  fe000000-fe1fffff : isa-mmio


With your patch:

(qemu) info mtree 
memory
00000000-fffffffe : system
  80013000-8001303f : escc
  fee00000-fee00fff : pci-data-idx
  fec00000-fec00fff : pci-conf-idx
  80000000-fdffffff : pci-hole
  fe000000-fe1fffff : isa-mmio



Since the VRAM is mapped to 0x80000000 which is now occupied by the hole and nothing behind it, nothing gets to write there? Not sure - I still haven't understood how the memory api works.


Alex
Avi Kivity - Sept. 19, 2011, 9:22 a.m.
On 09/19/2011 12:15 PM, Alexander Graf wrote:
> On 17.09.2011, at 23:40, Blue Swirl wrote:
>
> >  On Thu, Sep 15, 2011 at 11:31 AM, Avi Kivity<avi@redhat.com>  wrote:
> >>  On 09/15/2011 01:01 PM, Benjamin Herrenschmidt wrote:
> >>>
> >>>>   Sure :). So the problem is that when emulating the G3 Beige machine in
> >>>>   QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently,
> >>>>   on x86 that PCI VGA adapter can map the special VGA regions to
> >>>>   somewhere, namely 0xa0000. With the memory api overhaul, this also
> >>>>   slipped into the PPC world where mapping 0xa0000 with VGA adapters is
> >>>>   a pretty bad idea, as it's occupied by RAM.
> >>>>
> >>>>   Now the discussion was on which level that mapping would happen and
> >>>>   which devices go through which buses which then would filter certain
> >>>>   ranges from being mapped. Basically, which way does a memory request
> >>>>   from the CPU go on a G3 Beige machine until it arrives the VGA
> >>>>   adapter?
> >>>>
> >>>>   I hope that concludes the actual question. Avi, if I explained this
> >>>>   wrong, please correct me.
> >>>
> >>>  Ok so there's several things here.
> >>>
> >>>  First, the mapping from CPU addresses to PCI addresses. This depends on
> >>>  the host bridge chip. The MPC106, used in the Beige G3, itself supports
> >>>  different type of mappings.
> >>>
> >>>    From memory, the way it's configured in a G3 is to have a 1:1 mapping of
> >>>  80000000 CPU to 80000000 PCI.
> >>>
> >>>  That means that with this basic mapping, you cannot generate memory
> >>>  accesses to low PCI addresses such as 0xa0000.
> >>
> >>  Alex, what this means (I think is) that: pci_grackle_init() needs to create
> >>  a container memory region and pass it to pc_register_bus() as the pci
> >>  address space, and create and alias starting at 0x80000000 of the pci
> >>  address space, and map that alias at address 0x80000000 of the system
> >>  address space.
> >>
> >>  See pc_init1() creating pci_memory and passing it to i440fx_init(), which
> >>  then maps some aliases into the system address space and also gives it to
> >>  pci_bus_new().  It's essentially the same thing with different details.
> >
> >  I think the attached patch (on top of ppc-next) should do it, but it
> >  doesn't. Only the top area of the screen is shown, the rest is black.
>
> Without your patch:
>
> (qemu) info mtree
> memory
> 00000000-fffffffe : system
>    800a0000-800affff : vga.chain4
This is here due to the isa_mem_base problem - I think we can get that 
part of the patch merged?

>    80880000-808fffff : macio
>      00060000-0007ffff : macio-nvram
>      00020000-00020fff : pmac-ide
>      00016000-00017fff : cuda
>      00013000-0001303f : escc-bar
>      00008000-00008fff : dbdma
>      00000000-00000fff : heathrow-pic
>    80800000-8080ffff : vga.rom
>    80000000-807fffff : vga.vram
>    800a0000-800bffff : vga-lowmem
>    80013000-8001303f : escc
>    fee00000-fee00fff : pci-data-idx
>    fec00000-fec00fff : pci-conf-idx
>    fe000000-fe1fffff : isa-mmio
>
>
> With your patch:
>
> (qemu) info mtree
> memory
> 00000000-fffffffe : system
>    80013000-8001303f : escc
>    fee00000-fee00fff : pci-data-idx
>    fec00000-fec00fff : pci-conf-idx
>    80000000-fdffffff : pci-hole
>    fe000000-fe1fffff : isa-mmio
>
>
>
> Since the VRAM is mapped to 0x80000000 which is now occupied by the hole and nothing behind it, nothing gets to write there?

The memory printer doesn't follow aliases, so this is incomplete.

> Not sure - I still haven't understood how the memory api works.
>

Thanks for reminding me to write up slides for tomorrow's code overview 
session.  I'll start with a general explanation.
Alexander Graf - Sept. 19, 2011, 9:36 a.m.
On 19.09.2011, at 11:22, Avi Kivity wrote:

> On 09/19/2011 12:15 PM, Alexander Graf wrote:
>> On 17.09.2011, at 23:40, Blue Swirl wrote:
>> 
>> >  On Thu, Sep 15, 2011 at 11:31 AM, Avi Kivity<avi@redhat.com>  wrote:
>> >>  On 09/15/2011 01:01 PM, Benjamin Herrenschmidt wrote:
>> >>>
>> >>>>   Sure :). So the problem is that when emulating the G3 Beige machine in
>> >>>>   QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently,
>> >>>>   on x86 that PCI VGA adapter can map the special VGA regions to
>> >>>>   somewhere, namely 0xa0000. With the memory api overhaul, this also
>> >>>>   slipped into the PPC world where mapping 0xa0000 with VGA adapters is
>> >>>>   a pretty bad idea, as it's occupied by RAM.
>> >>>>
>> >>>>   Now the discussion was on which level that mapping would happen and
>> >>>>   which devices go through which buses which then would filter certain
>> >>>>   ranges from being mapped. Basically, which way does a memory request
>> >>>>   from the CPU go on a G3 Beige machine until it arrives the VGA
>> >>>>   adapter?
>> >>>>
>> >>>>   I hope that concludes the actual question. Avi, if I explained this
>> >>>>   wrong, please correct me.
>> >>>
>> >>>  Ok so there's several things here.
>> >>>
>> >>>  First, the mapping from CPU addresses to PCI addresses. This depends on
>> >>>  the host bridge chip. The MPC106, used in the Beige G3, itself supports
>> >>>  different type of mappings.
>> >>>
>> >>>    From memory, the way it's configured in a G3 is to have a 1:1 mapping of
>> >>>  80000000 CPU to 80000000 PCI.
>> >>>
>> >>>  That means that with this basic mapping, you cannot generate memory
>> >>>  accesses to low PCI addresses such as 0xa0000.
>> >>
>> >>  Alex, what this means (I think is) that: pci_grackle_init() needs to create
>> >>  a container memory region and pass it to pc_register_bus() as the pci
>> >>  address space, and create and alias starting at 0x80000000 of the pci
>> >>  address space, and map that alias at address 0x80000000 of the system
>> >>  address space.
>> >>
>> >>  See pc_init1() creating pci_memory and passing it to i440fx_init(), which
>> >>  then maps some aliases into the system address space and also gives it to
>> >>  pci_bus_new().  It's essentially the same thing with different details.
>> >
>> >  I think the attached patch (on top of ppc-next) should do it, but it
>> >  doesn't. Only the top area of the screen is shown, the rest is black.
>> 
>> Without your patch:
>> 
>> (qemu) info mtree
>> memory
>> 00000000-fffffffe : system
>>   800a0000-800affff : vga.chain4
> This is here due to the isa_mem_base problem - I think we can get that part of the patch merged?
> 
>>   80880000-808fffff : macio
>>     00060000-0007ffff : macio-nvram
>>     00020000-00020fff : pmac-ide
>>     00016000-00017fff : cuda
>>     00013000-0001303f : escc-bar
>>     00008000-00008fff : dbdma
>>     00000000-00000fff : heathrow-pic
>>   80800000-8080ffff : vga.rom
>>   80000000-807fffff : vga.vram
>>   800a0000-800bffff : vga-lowmem

Well what I don't understand is how this corresponds to the lowmem region here. If I simply #if 0 the chain4 code out, everything works as expected.

>>   80013000-8001303f : escc
>>   fee00000-fee00fff : pci-data-idx
>>   fec00000-fec00fff : pci-conf-idx
>>   fe000000-fe1fffff : isa-mmio
>> 
>> 
>> With your patch:
>> 
>> (qemu) info mtree
>> memory
>> 00000000-fffffffe : system
>>   80013000-8001303f : escc
>>   fee00000-fee00fff : pci-data-idx
>>   fec00000-fec00fff : pci-conf-idx
>>   80000000-fdffffff : pci-hole
>>   fe000000-fe1fffff : isa-mmio
>> 
>> 
>> 
>> Since the VRAM is mapped to 0x80000000 which is now occupied by the hole and nothing behind it, nothing gets to write there?
> 
> The memory printer doesn't follow aliases, so this is incomplete.

Ugh :(.

> 
>> Not sure - I still haven't understood how the memory api works.
>> 
> 
> Thanks for reminding me to write up slides for tomorrow's code overview session.  I'll start with a general explanation.

What code overview session?


Alex
Avi Kivity - Sept. 19, 2011, 9:48 a.m.
On 09/19/2011 12:36 PM, Alexander Graf wrote:
> >
> >>    80880000-808fffff : macio
> >>      00060000-0007ffff : macio-nvram
> >>      00020000-00020fff : pmac-ide
> >>      00016000-00017fff : cuda
> >>      00013000-0001303f : escc-bar
> >>      00008000-00008fff : dbdma
> >>      00000000-00000fff : heathrow-pic
> >>    80800000-8080ffff : vga.rom
> >>    80000000-807fffff : vga.vram
> >>    800a0000-800bffff : vga-lowmem
>
> Well what I don't understand is how this corresponds to the lowmem region here. If I simply #if 0 the chain4 code out, everything works as expected.

It's at the wrong address.  It should be at 000a0000, but not be visible 
since it's outside the pci hole.  IIUC.

> >
> >>  Not sure - I still haven't understood how the memory api works.
> >>
> >
> >  Thanks for reminding me to write up slides for tomorrow's code overview session.  I'll start with a general explanation.
>
> What code overview session?
>

At the usual kvm weekly time & place, I'll do a walkthrough of the 
memory API theory and practice.

Patch

From c07f1116220cba7d2ee769b03de59b5a874b76db Mon Sep 17 00:00:00 2001
Message-Id: <c07f1116220cba7d2ee769b03de59b5a874b76db.1316295419.git.blauwirbel@gmail.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Sat, 17 Sep 2011 20:30:50 +0000
Subject: [PATCH] PPC: use memory API to construct the PCI hole

Avoid vga.chain4 mapping by constructing a PCI hole for upper
2G of the PCI space.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
---
 hw/grackle_pci.c  |   11 ++++++++++-
 hw/ppc_newworld.c |    2 --
 hw/ppc_oldworld.c |    2 --
 hw/unin_pci.c     |   18 ++++++++++++++++--
 4 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index 9d3ff7d..94a608e 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -41,6 +41,8 @@ 
 typedef struct GrackleState {
     SysBusDevice busdev;
     PCIHostState host_state;
+    MemoryRegion pci_mmio;
+    MemoryRegion pci_hole;
 } GrackleState;
 
 /* Don't know if this matches real hardware, but it agrees with OHW.  */
@@ -73,11 +75,18 @@  PCIBus *pci_grackle_init(uint32_t base, qemu_irq *pic,
     qdev_init_nofail(dev);
     s = sysbus_from_qdev(dev);
     d = FROM_SYSBUS(GrackleState, s);
+
+    memory_region_init(&d->pci_mmio, "pci-mmio", 0x100000000ULL);
+    memory_region_init_alias(&d->pci_hole, "pci-hole", &d->pci_mmio,
+                             0x80000000ULL, 0x7e000000ULL);
+    memory_region_add_subregion(address_space_mem, 0x80000000ULL,
+                                &d->pci_hole);
+
     d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
                                          pci_grackle_set_irq,
                                          pci_grackle_map_irq,
                                          pic,
-                                         address_space_mem,
+                                         &d->pci_mmio,
                                          address_space_io,
                                          0, 4);
 
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index 5fb9359..bcdc0a3 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -263,8 +263,6 @@  static void ppc_core99_init (ram_addr_t ram_size,
         }
     }
 
-    isa_mem_base = 0x80000000;
-
     /* Register 8 MB of ISA IO space */
     isa_mmio_init(0xf2000000, 0x00800000);
 
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 3857075..5c17944 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -208,8 +208,6 @@  static void ppc_heathrow_init (ram_addr_t ram_size,
         }
     }
 
-    isa_mem_base = 0x80000000;
-
     /* Register 2 MB of ISA IO space */
     isa_mmio_init(0xfe000000, 0x00200000);
 
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 600cd1e..4299052 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -41,6 +41,8 @@  static const int unin_irq_line[] = { 0x1b, 0x1c, 0x1d, 0x1e };
 typedef struct UNINState {
     SysBusDevice busdev;
     PCIHostState host_state;
+    MemoryRegion pci_mmio;
+    MemoryRegion pci_hole;
 } UNINState;
 
 static int pci_unin_map_irq(PCIDevice *pci_dev, int irq_num)
@@ -215,10 +217,16 @@  PCIBus *pci_pmac_init(qemu_irq *pic,
     qdev_init_nofail(dev);
     s = sysbus_from_qdev(dev);
     d = FROM_SYSBUS(UNINState, s);
+    memory_region_init(&d->pci_mmio, "pci-mmio", 0x100000000ULL);
+    memory_region_init_alias(&d->pci_hole, "pci-hole", &d->pci_mmio,
+                             0x80000000ULL, 0x70000000ULL);
+    memory_region_add_subregion(address_space_mem, 0x80000000ULL,
+                                &d->pci_hole);
+
     d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
                                          pci_unin_set_irq, pci_unin_map_irq,
                                          pic,
-                                         address_space_mem,
+                                         &d->pci_mmio,
                                          address_space_io,
                                          PCI_DEVFN(11, 0), 4);
 
@@ -272,10 +280,16 @@  PCIBus *pci_pmac_u3_init(qemu_irq *pic,
     s = sysbus_from_qdev(dev);
     d = FROM_SYSBUS(UNINState, s);
 
+    memory_region_init(&d->pci_mmio, "pci-mmio", 0x100000000ULL);
+    memory_region_init_alias(&d->pci_hole, "pci-hole", &d->pci_mmio,
+                             0x80000000ULL, 0x70000000ULL);
+    memory_region_add_subregion(address_space_mem, 0x80000000ULL,
+                                &d->pci_hole);
+
     d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
                                          pci_unin_set_irq, pci_unin_map_irq,
                                          pic,
-                                         address_space_mem,
+                                         &d->pci_mmio,
                                          address_space_io,
                                          PCI_DEVFN(11, 0), 4);
 
-- 
1.7.2.5