Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

[Alexander Graf]

On 17.09.2011, at 23:40, Blue Swirl wrote:

> On Thu, Sep 15, 2011 at 11:31 AM, Avi Kivity <address@hidden> 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