From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qxfny-0003pY-99 for qemu-devel@nongnu.org; Sun, 28 Aug 2011 09:53:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qxfnx-0007HU-8E for qemu-devel@nongnu.org; Sun, 28 Aug 2011 09:53:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qxfnx-0007HM-1E for qemu-devel@nongnu.org; Sun, 28 Aug 2011 09:53:41 -0400 Message-ID: <4E5A485D.1020904@redhat.com> Date: Sun, 28 Aug 2011 16:53:33 +0300 From: Avi Kivity MIME-Version: 1.0 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> In-Reply-To: <20110828134203.GA6751@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 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. 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. -- error compiling committee.c: too many arguments to function