From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5FY3-0004ir-9c for qemu-devel@nongnu.org; Sun, 18 Sep 2011 07:28:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5FY2-00089I-6d for qemu-devel@nongnu.org; Sun, 18 Sep 2011 07:28:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5FY1-000892-Sk for qemu-devel@nongnu.org; Sun, 18 Sep 2011 07:28:34 -0400 Message-ID: <4E75D5D8.4050001@redhat.com> Date: Sun, 18 Sep 2011 14:28:24 +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> <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> In-Reply-To: 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: Blue Swirl Cc: Anthony Liguori , qemu-devel Developers , Alexander Graf , =?ISO-8859-1?Q?Andreas_F=E4rber?= , Gerd Hoffmann , Jan Kiszka , Richard Henderson On 09/18/2011 12:40 AM, 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. I can't see anything wrong with the patch either. -- error compiling committee.c: too many arguments to function