From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EP2-0000vV-7n for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:14:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0EP0-00015t-Oi for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:14:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0EP0-00015p-EZ for qemu-devel@nongnu.org; Sun, 04 Sep 2011 11:14:30 -0400 Message-ID: <4E6395CE.3010309@redhat.com> Date: Sun, 04 Sep 2011 18:14:22 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20110828134203.GA6751@redhat.com> <4E5A485D.1020904@redhat.com> <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> In-Reply-To: <20110904145425.GC27239@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Isaku Yamahata , qemu-devel@nongnu.org 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? Note that most/all cpus don't. We may need 65-bit arithmetic for that. > > > >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. (vga registers its legacy space as a subregion of pci_address_space(dev)) -- error compiling committee.c: too many arguments to function