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<a...@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.
--
error compiling committee.c: too many arguments to function
