Re: [Xen-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2015-02-05 at 09:22 +0800, Chen, Tiejun wrote:
> Indeed this is not something workaround, and I think in any type of VGA 
> devices, we'd like to diminish this sort of thing gradually, right?
> 
> This mightn't come true in real world :)

It's not really something we can control, the h/w guys will do what they
do, including integrating on-board graphics tightly with the N/S-bridges
etc.

> >
> > I think there are three ways to achieve that:
> >
> >        * Make the libxl/xl option something which is not generic e.g.
> >          igd_passthru=1
> >        * Add a second option to allow the user to configure the kind of
> >          graphics device being passed thru (e.g. gfx_passthru=1,
> >          passthru_device="igd"), or combine the two by making the
> >          gfx_passthru option a string instead of a boolean.
> 
> It makes more sense but this mean we're going to change that existing 
> rule in qemu-traditional. But here I guess we shouldn't consider that case.

qemu-trad is frozen so we wouldn't be adding new features such as
support for new graphics passthru devices, so we can ignore it's
deficiencies in this area and just improve things in the qemu-xen case.
(we may want to add a compat handling for any new option we add to libxl
to translate to -gfx_passthru, but that's about it)

> >        * Make libxl detect the type of graphics device somehow and
> >          therefore automatically determine when gfx_passthru=1 =>
> >          igd-passthru
> 
> This way confounds me all. Can libxl detect the graphics device *before* 
> we intend to pass a parameter to active qemu?

We know the BDF of all devices which we are going to pass to the guest
and we can observe various properties of that device
via /sys/bus/pci/devices/0000:B:D:F.

> 
> >
> >>   Currently, we have to set
> >> something as follows,
> >>
> >> gfx_passthru=1
> >> pci=["00:02.0"]
> >>
> >> This always works for qemu-xen-traditional.
> >>
> >> But you should know '00:02.0' doesn't mean we are passing IGD through.
> >
> > But by looking at the device 00:02.0 (e.g. its PCI vendor and device ID
> > and other properties) we can unambiguously determine if it is an IGD
> > device or not, can't we?
> 
> Again, like what I said above, I'm not sure if its possible in my case. 
> If I'm wrong please correct me.

Is my reply above sufficient?

> >>> If not then that _might_ suggest we should deprecate the gdx_passthru
> >>> option at the libxl interface and switch to something more expressive,
> >>> such as an Enumeration of card types (with a singleton of IGD right
> >>> now), but I'm not really very familiar with passthru nor the qemu side
> >>> of this.
> >>>
> >>> What happens if you try to pass two different GFX cards to a guest?
> >>>
> >>
> >> Are you saying two IGDs?
> >
> > Yes, or any combination of two cards, perhaps from different vendors
> > (AIUI some laptops have this with IGD and Nvidia or ATI?).
> 
> One IGD and multiple other type of Graphic display cards can coexist.

... but if they both need special handling then we need a way to
communicate that.

> >>   Its not possible since as I said above, IGD is
> >> tricky because it depends on something from ISA bridge and host bridge.
> >> So we can't provide two or more different setting configurations to own
> >> more IGDs just in one platform.
> >
> > This is because IGD must be a "primary" VGA device? I understand that
> 
> No. I mean ISA bridge and host bridge just provide one set of IGD 
> resource so its difficult to configure two or more IGDs.
> 
> > there can only be one of those in a system, but I think it is possible
> > to have multiple secondary VGA devices or different types in one system.
> >
> 
> What I'm saying is, its impossible to own two same IGDs in our current 
> platform :)

Understood, but systems needn't be homogeneous wrt graphics devices.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel