From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5a3R-0004HA-UP for qemu-devel@nongnu.org; Mon, 19 Sep 2011 05:22:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5a3M-0000dA-12 for qemu-devel@nongnu.org; Mon, 19 Sep 2011 05:22:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5a3L-0000cp-Pw for qemu-devel@nongnu.org; Mon, 19 Sep 2011 05:22:15 -0400 Message-ID: <4E7709BD.3060404@redhat.com> Date: Mon, 19 Sep 2011 12:22:05 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E6F1BAF.2000105@siemens.com> <2A74238E-5C89-444B-9DB9-4B380D182AC3@suse.de> <4E6F3FB8.6060705@siemens.com> <4E7053A3.8090508@redhat.com> <4E706303.9040502@redhat.com> <4E7063D9.3040803@siemens.com> <4E70645D.8050100@redhat.com> <4E7064BA.1050700@siemens.com> <58B7465A-925F-4732-A557-AB57BEFCD64B@suse.de> <4E706763.8020706@redhat.com> <14B02BB3-FFB5-4B67-B0AC-6E6A9806AE0E@suse.de> <219F7C53-89AB-4824-B78C-E31E99E3A50C@suse.de> <1316049883.455.178.camel@pasglop> <98A5FA69-192E-4CB6-846F-C296B825085C@suse.de> <1316080881.455.192.camel@pasglop> <4E71E219.9090306@redhat.com> <616B65DF-C100-4F0F-9EDC-CCF9C72007F0@suse.de> In-Reply-To: <616B65DF-C100-4F0F-9EDC-CCF9C72007F0@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , qemu-devel Developers , Blue Swirl , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Gerd Hoffmann , Jan Kiszka , Richard Henderson 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 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