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
