On Fri, 2013-02-01 at 08:44 +1100, Benjamin Herrenschmidt wrote: > 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... Yep, converting Endpoint to Integrated Endpoint is just a matter of changing the guest visible type and hiding all the link(2) cap, control, and status. Integrated Endpoint to Endpoint appears to require inventing some link capabilities since it's a required field. Legacy Endpoint to Integrated Endpoint seems incompatible, but I don't think we model anything at a level that would care. We could also take the opportunity to remove the PCIe capability when exposing devices on 440fx, but I'm nervous that would break drivers that are dumb and look for it anyway. > Typically on my laptop with intel chipset, bus 0 has devices that just > don't have any PCIe capabilities. Oddly the audio device seems to be the only one that consistently has it. > > 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. Yes, our emulated root ports should include this, otherwise we have little hope of properly supporting multiple assigned (or emulated) graphics devices, each behind their own root port. So we need the ability for multiple devices to register VGA address (1 per bus?) and change MemoryRegion routing just like hardware does. > > 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 ? Perhaps. This is an Intel GS45[1], section 4 talks about VGA routing rules. Thanks, Alex [1] http://www.intel.com/Assets/PDF/datasheet/320122.pdf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
