Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O

[Benjamin Herrenschmidt]

On Thu, 2013-01-31 at 09:34 -0700, Alex Williamson wrote:
> > Luckily guests do not seem to be worried as long as we use ACPI.
> 
> Yes, in fact I just figured out last night that Windows is unhappy with
> assigned PCI devices on bus 0 that claim to be an endpoint in their PCIe
> capability rather than an integrated endpoint.  We'll need to do extra
> mangling of the PCIe capability to massage it into the guest visible
> topology.

If you are on bus 0, you need to either not have the capability, or if
you do, have it be root complex or RC intergrated endpoint. It's fair
game for any OS to assume that an endpoint will have a parent bridge
(either a RC or a downstream port) and to muck around with link control
etc...

Typically on my laptop with intel chipset, bus 0 has devices that just
don't have any PCIe capabilities.

> Section 1.3.2.3 of the 3.0 spec says integrated endpoints must not
> require I/O resources claimed through BAR(s).  VGA skirts around this by
> not having the legacy resources claimed by BARs, but instead being
> implicit.  Are there other sections restricting legacy I/O?

Right this is odd, I don't know why they put that in. Legacy endpoints
don't have that limitation and I doubt system software actually cares.

On the other hand, I suspect that doesn't apply if you simply doesn't
have the PCIe capability at all :-) IE, that's basically what my laptop
looks like here. The Intel graphics appears on bus 0 and has IO ports
mapped with a BAR and no PCIe cap.

Same with the on-chip SATA.

In fact they have a "PCI Advanced features" capability, but not PCIe.

Then they have a bunch of root complexes as siblings.

> It's common that a plugin VGA card sits behind a root port where the
> bridge registers tell us about VGA routing, but integrated VGA devices
> are often on bus 0 though, here's an example:
> 
> -[0000:00]-+-00.0  Intel Corporation 2nd Generation Core Processor Family 
> DRAM Controller
>            +-02.0  Intel Corporation 2nd Generation Core Processor Family 
> Integrated Graphics Controller
> 
> Often these systems will disable the integrated graphics when a plugin
> graphics is installed below a root port.  I'm not sure how the system
> knows to route VGA to the integrated device vs the root port otherwise.

It's a good question... I would say the "cleanest" way is to use the VGA
Enable bit of the root complex. If the RC is set to forward downstream,
then the plug-in card gets the VGA cycles, else, they go to the
integrated one (substractive decoding -style).

However, the PCI-E spec has removed that bit from the bridge control
register definition :-)

So whatever mechanism those chipsets use has to be somewhat proprietary.

On the other hand, I don't see it hurting to make our own "proprietary"
mechanism consist of using ... the bridge control VGA enable bit. IE.
The bit is not used in the PCIe spec and probably never will be so we
can use it for its original purpose.

> Here's a more interesting example:
> 
> -+-[0000:01]-+-00.0  NVIDIA Corporation GT218 [GeForce G210M]
>  |           \-00.1  NVIDIA Corporation High Definition Audio Controller
>  \-[0000:00]-+-00.0  Intel Corporation Mobile 4 Series Chipset Memory 
> Controller Hub
>              +-01.0  Intel Corporation Mobile 4 Series Chipset PCI Express 
> Graphics Port
> 
> This system seems to have two host bridges with VGA behind each of them.
> There's no bridge to control VGA routing, so I don't know how the
> selection is done.  It's possible the g210m never sees legacy VGA
> accesses in this mode.  This bios has another mode which makes the g210m
> the primary graphics and hides the integrated graphics, essentially the
> same as I mention above with hiding integrated endpoint graphics when
> plugin graphics are used.  Thanks,

Wait, those are two different busses ... and there's no bridge ? Is that
the funky x86 multi domain crackpot where you have multiple roots with
non overlapping bus numbers in the same domain ?

Ben.