qemu-devel
[Top][All Lists]
Advanced

[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: Alexander Graf
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 11:36:05 +0200

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




reply via email to

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