From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QxdkJ-0004Uu-Dn for qemu-devel@nongnu.org; Sun, 28 Aug 2011 07:41:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QxdkI-0002sX-B9 for qemu-devel@nongnu.org; Sun, 28 Aug 2011 07:41:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QxdkI-0002rU-16 for qemu-devel@nongnu.org; Sun, 28 Aug 2011 07:41:46 -0400 Date: Sun, 28 Aug 2011 14:41:42 +0300 From: "Michael S. Tsirkin" Message-ID: <20110828114142.GC4875@redhat.com> References: <20110704094358.GA10960@redhat.com> <4E4B7DE1.3050405@cn.fujitsu.com> <4E4C8577.5000608@cn.fujitsu.com> <4E4D2C9F.6040805@redhat.com> <20110826094254.GA6520@redhat.com> <4E59F359.9040506@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E59F359.9040506@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, Aug 28, 2011 at 10:50:49AM +0300, Avi Kivity wrote: > On 08/26/2011 12:43 PM, Michael S. Tsirkin wrote: > >On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote: > >> It's correct but insufficient, the filtering code > >> (pci_bridge_filter) needs to be updated to use the memory API. > >> > >> Basically it gets simpler and correcter. > > > >I've been struggling with the following problem: bridges have two memory > >ranges: prefetcheable and non-prefetcheable. > > > >Memory in the device can be behind the prefetcheable and > >non-prefetcheable memory range, but things only work correctly if > >non-prefetcheable memory on the device is put behind a non-prefetcheable > >range. Prefetcheable memory can go anywhere I think. > > > >This didn't work correctly before the memory API change, > >but it was easy to fix ... Now I'm not sure how. > > If it really matters, you can add a prefetchability attribute to > MemoryRegions. Does it though? Well, its another one of these things that guests *probably* won't in practice use. But I don't see a way to be sure. If the guest puts a prefetcheable memory BAR behind a non-prefetcheable range in the bridge, it won't be able to access that BAR, and it should. Prefetcheable BARs on devices are less common than non-prefetcheable, but they do exist: I have a system with 2 devices: a VGA controller from Matrox and an ethernet card from Mellanox have prefetcheable BARs. I'm not sure how prefetcheability attribute will help. Could you explain pls? > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain.