Re: [Qemu-devel] [PATCH] pci: add standard bridge device

[Avi Kivity]

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