From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AAW-0006ka-My for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:31:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4AAV-0002Mj-DD for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:31:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AAV-0002Mb-4n for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:31:47 -0400 Message-ID: <4E71E219.9090306@redhat.com> Date: Thu, 15 Sep 2011 14:31:37 +0300 From: Avi Kivity MIME-Version: 1.0 References: <6BA6355D-D77A-40F4-A8C4-61901A926E71@suse.de> <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> <4E710BAB. 6060705@redhat.com> <4E7111BB.107 0608@twiddle.net> <219F7C53-89AB-4824-B78C-E31E99E3A50C@suse.de> <1316049883.455.178.camel@pasglop> <98A5FA69-192E-4CB6-846F-C296B825085C@suse.de> <1316080881.455.192.camel@pasglop> In-Reply-To: <1316080881.455.192.camel@pasglop> Content-Type: text/plain; charset=UTF-8; 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: Benjamin Herrenschmidt Cc: Anthony Liguori , Jan Kiszka , qemu-devel Developers , Alexander Graf , Blue Swirl , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Gerd Hoffmann , Richard Henderson 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