From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Bp6-0006ze-EL for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:29:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0Bp5-0006bh-6R for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:29:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0Bp4-0006bV-Tf for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:29:15 -0400 Date: Sun, 4 Sep 2011 15:30:06 +0300 From: "Michael S. Tsirkin" Message-ID: <20110904123006.GA23500@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> <20110828114142.GC4875@redhat.com> <4E5A3E36.4010709@redhat.com> <20110828134203.GA6751@redhat.com> <4E5A485D.1020904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5A485D.1020904@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 04:53:33PM +0300, Avi Kivity wrote: > On 08/28/2011 04:42 PM, Michael S. Tsirkin wrote: > >On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote: > >> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote: > >> >> > >> >> 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. > >> > >> Not sure I understand - on real hardware, does it see the BAR or not? > > > >It does. > > Ok, was different from what I thought. So anything that matches the > two windows is exposed (after clipping). If the guest enables the > legacy vga range, then there are three regions, with equal > treatment, yes? > > >ATM we have each BAR as a memory region, which is > >in turn within io or memory address space region. > >With bridges, each bridge has a single range > >covering legal io addresses below it, and two ranges for memory. > > > >Example from a real system: > > Memory behind bridge: 98200000-982fffff > > Prefetchable memory behind bridge: 0000000097000000-00000000977fffff > > > >And a device can have: > > > > Region 0: Memory at 98200000 (64-bit, non-prefetchable) [size=1M] > > Region 2: Memory at 97000000 (64-bit, prefetchable) [size=8M] > > > > > >guest can in theory reprogram this: > > > > Memory behind bridge: 98200000-98afffff > > Prefetchable memory behind bridge: 0000000097000000-00000000977fffff > > > >and > > Region 0: Memory at 98200000 (64-bit, non-prefetchable) [size=1M] > > Region 2: Memory at 98300000 (64-bit, prefetchable) [size=8M] > > > >and the device will work (presumably, guests will try to avoid this > >as they assume prefetchable ranges are faster). > > >Thus, which range the device BAR is behind depends on the > >programmed values. How do we model that? > > Create a memory region for the bridge's address space. This region > is not directly added to system_memory or its descendants. I do this for each bridge in the hierarchy, right? > Devices > under the bridge see this region as its pci_address_space(). The > region is as large as the entire address space - it does not take > into account any windows. > > For each of the three windows (pref, non-pref, vga), create an alias > with the appropriate start and size. Map the alias into the > bridge's parent's pci_address_space(), as subregions. > > fx440 does exactly this, with the following cosmetic changes: > > - the windows are different (vga, pci hole, 64-bit pci area, PAMx, SMRAM) > - instead of mapping them to the parent bridge's > pci_address_space(), we map them to get_system_memory() > > >A side note on bus filtering: > >In cases of bus range partially hinding the BAR from the guest, one can > >even have multiple non-contigious bits of the BAR visible and the rest > >hidden. > > The memory API will deal with this perfectly. > > >I'm not saying it's very important to model this, > >I'm guessing the only important cases are all of the > >BAR visible and all of the BAR hidden. > > It should all work. Including a sub-bridge's windows being > fragmented by the parent bridge. Too bad it doesn't matter in > practice, because it's a really neat solution to this non-problem. Hmm, what ties the windows of a child bridge to be within the windows of a parent? > -- > error compiling committee.c: too many arguments to function