qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Williamson
Subject: Re: [Qemu-ppc] [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O
Date: Thu, 31 Jan 2013 16:25:11 -0700

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]