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: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode
Date: Thu, 15 Sep 2011 14:31:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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




reply via email to

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