From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3vs7-0001gF-IE for qemu-devel@nongnu.org; Wed, 14 Sep 2011 16:15:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3vs5-0003s6-ST for qemu-devel@nongnu.org; Wed, 14 Sep 2011 16:15:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3vs5-0003rG-J9 for qemu-devel@nongnu.org; Wed, 14 Sep 2011 16:15:49 -0400 Message-ID: <4E710B70.6020709@redhat.com> Date: Wed, 14 Sep 2011 23:15:44 +0300 From: Avi Kivity MIME-Version: 1.0 References: <3d9d904a1e4939a147f8954c9e0d4cdaf3d44c31.1314033132.git.jan.kiszka@siemens.com> <4E6E2329.9050109@suse.de> <4E6E2631.4060300@siemens.com> <4E6E28FD.7070907@web.de> <4E6E2A06.8010900@siemens.com> <4E6E2BDC.3060702@siemens.com> <4E6F10DD.6060606@siemens.com> <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> In-Reply-To: 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: Blue Swirl Cc: Anthony Liguori , Jan Kiszka , qemu-devel , Alexander Graf , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Gerd Hoffmann On 09/14/2011 11:06 PM, Blue Swirl wrote: > On Wed, Sep 14, 2011 at 8:35 AM, Avi Kivity wrote: > > On 09/14/2011 11:27 AM, Alexander Graf wrote: > >> > >> On 14.09.2011, at 10:24, Jan Kiszka wrote: > >> > >> > On 2011-09-14 10:22, Avi Kivity wrote: > >> >> On 09/14/2011 11:20 AM, Jan Kiszka wrote: > >> >>>> > >> >>>> Anyway PCI supports the vga region at 0xa0000-0xc0000. Where is it > >> >>>> supposed to be mapped? > >> >>> > >> >>> ...but not all PCI bridges make use of this feature / forward legacy > >> >>> requests. > >> >>> > >> >> > >> >> Then this should be fixed in the bridge? > >> > > >> > Yes, it's a PPC bug. > >> > >> So how does the bridge not forward it then? > >> > > > > I expect that currently vga adds the region to pci_address_space(). We need > > to create a pci_address_space_vga() function that returns a region for vga > > to use. Then add or remove the region to pci_address_space(), within the > > bridge code, depending on whether the bridge forwards vga accesses or not. > > Similar treatment should be also needed for VGA IO ports 0x3b0 etc. > > > (assuming I understood the problem correctly - not sure) > > I think you did. Maybe, but the solution can't be right. The bridge can't distinguish between a BAR mapped at 0xa0000 and the vga device claiming accesses to 0xa0000. Is this what is happening? The current pci bridge implementation (440fx) uses an alias to instantiate pci 0xa0000-0xc0000 at the same address in the host address space. If you disable it, those addresses map back to RAM - but there is no distinction between a BAR at that address and a VGA card at that address. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.