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