From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzkgz-000743-89 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 03:03:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rzkgt-0000cd-GN for qemu-devel@nongnu.org; Tue, 21 Feb 2012 03:03:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzkgt-0000cP-9o for qemu-devel@nongnu.org; Tue, 21 Feb 2012 03:03:15 -0500 Message-ID: <4F434FB3.1000006@redhat.com> Date: Tue, 21 Feb 2012 09:02:59 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4F3E5736.5060606@redhat.com> <20120220224001.GA22036@redhat.com> In-Reply-To: <20120220224001.GA22036@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv2-RFC 2/2] 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, kvm@vger.kernel.org, Avi Kivity Hi, >> This seems to not support 64bit prefetchable memory windows, at least >> linux doesn't think it does, lspci looks like this: >> >> 00:10.0 PCI bridge: Red Hat, Inc. Device 0001 (prog-if 00 [Normal decode]) [ ... ] >> Memory behind bridge: f6000000-f60fffff >> Prefetchable memory behind bridge: f8000000-fbffffff > What in the above tells you that 64 bit windows are not supported? lspci prints 64bit addresses then, like this: 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) [ ... ] I/O behind bridge: 00008000-00008fff Memory behind bridge: c0000000-c01fffff Prefetchable memory behind bridge: 00000000c0200000-00000000c03fffff > BAR0 is 32 bit non prefetcheable. As far as I can see linux driver > takes no precautions against access combining that can > happen with prefetcheable BARs, so non-prefetcheable > seems safer. I'm not talking about bar #0, but about the prefetchable memory window for devices behind the bridge. cheers, Gerd