From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EXV-0003JV-R8 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:23:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0EXU-0002o1-TB for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:23:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EXU-0002nv-If for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:23:16 -0400 Date: Sun, 4 Sep 2011 18:24:09 +0300 From: "Michael S. Tsirkin" Message-ID: <20110904152409.GA30376@redhat.com> References: <20110904123006.GA23500@redhat.com> <4E6371DA.7070304@redhat.com> <20110904130159.GB23500@redhat.com> <4E63778A.6050002@redhat.com> <20110904134101.GA27239@redhat.com> <4E638355.8030903@redhat.com> <20110904142152.GB27239@redhat.com> <4E638D08.10307@redhat.com> <20110904145425.GC27239@redhat.com> <4E6395CE.3010309@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6395CE.3010309@redhat.com> Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Isaku Yamahata , qemu-devel@nongnu.org On Sun, Sep 04, 2011 at 06:14:22PM +0300, Avi Kivity wrote: > On 09/04/2011 05:54 PM, Michael S. Tsirkin wrote: > >> Way too late. And also won't work, since often the offset is > >> determined by one party and the size by another. > > > >For things like BARs, yes - but these don't need to be > >that big normally. We could add an additinal API > >that gets first/last parameters. last< first means 0 size. > >Feasible? > > Let's defer this for now. > > Does PCI actually have 64-bit addresses? Yes. > Note that most/all cpus don't. > We may need 65-bit arithmetic for that. Jut using start/limit carefully should be enough ... > > > >> >VGA I/O addresses (including ISA aliases address - AD[15::10] are not > >> >decoded): > >> >AD[9::0] = 3B0h through 3BBh and 3C0h through 3DFh > >> > >> These "not decoded" bits mean you need to instantiate tons of > >> aliases to implement correctly. > >> I plan to add core support for that eventually. > > > >There's a flag to enable 16-bit decode actually: > >bit 4 in bridge control register. > >How does VGA work at the moment without a bridge? Ignores the ISA aliases? > >then we can do that too I think. > > > > Of course it doesn't ignore it. See the 440fx implementation, if > you disable VGA access (via the SMRAM register), vga goes away. Yes but that's for VGA RAM, right? I'm talking about the IO addresses: are tons of aliases created as you suggest? > (vga registers its legacy space as a subregion of pci_address_space(dev)) > > -- > error compiling committee.c: too many arguments to function