[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode
Date: Mon, 19 Sep 2011 12:22:05 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

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<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
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
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.

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]