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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2015-02-04 at 09:34 +0800, Chen, Tiejun wrote:
> >
> >>       "-machine xxx,igd-passthru=on", to enable/disable that feature.
> >>       And we also remove that old option, "-gfx_passthru", just from
> >>       the case of LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN since actually
> >>       no any qemu stream version really need or use that.
> >                     ^up ?
> >
> > What happens if you pass this new option to an older version of qemu
> > upstream? I suppose it doesn't fail any worse than passing -gfx_passthru
> > would have done.
> 
> Neither '-gfx_passthru' nor 'igd-passthrou' exists in any version of 
> qemu upstream. As I mentioned previously, just now we're starting to 
> support this in qemu upstream :)
> 
> But you known, on Xen side we have two qemu versions, 
> qemu-xen-traditional and qemu-xen. Although '-gfx_passthru' is adopted 
> in both two versions, just qemu-xen-traditional supports IGD passthrough 
> completely. For qemu-xen, we just have this term definition but without 
> that IGD passthrough feature support actually.

I'm afraid I don't follow, you seem to be simultaneously saying that
qemu-xen both does and does not support -gfx_passthru, which cannot be
right. I think from the following paragraph that what you mean is that
upstream qemu-xen has no support for any kind of -gfx_passthru command
line option in any form in any existing version, including the git tree.
Is that correct?

(for the purposes of this conversation qemu-traditional is not of
interest)

> And now we're trying to support IGD passthrough in qemu stream. This 
> mean we should set 'device_model_version="qemu-xen", right? Then libxl 
> still pass '-gfx_passthru' to qemu upstream. But when I post other 
> stuffs to qemu upstream community to support IGD passthrough. Gerd 
> thought "-machine xxx,igd-passthru=on" is better than '-gfx_passthru'. 
> So finally you see this change in Xen/tools/libxl.
> 
> >
> > I have one more general concern, which is that hardcoding igd-passthru
> > here may make it harder to support gfx_passthru of other cards in the
> > future.
> 
> Actually gfx_passthrou is introduced to just work for IGD passthrough 
> since something specific to IGD is tricky, so we have to need such a 
> flag to handle this precisely, like its fixed at 00:02.0, and expose 
> some ISA bridge PCI config info and even host bridge PCI config info.
> 
> So I don't thing other cards need this.

If one type VGA device needs these sorts of workaround it is not
inconceivable that some other one will also need workarounds in the
future.

Even if you don't consider non-IGD, what about the possibility of a
future IGD device which needs different (or additional, or fewer)
workarounds?

> > Somehow something in the stack needs to either detect or be told which
> > kind of card to passthrough. Automatic detection would be preferable,
> > but maybe being told by the user is the only possibility.
> 
> Based on the above explanation, something should be done before we 
> detect to construct that real card , so its difficulty to achieve this 
> goal currently.
> 
> >
> > Is there any way, given gfx_passthru as a boolean that libxl can
> > automatically figure out that IGD passthru is what is actually desired
> > -- e.g. by scanning the set of PCI devices given to the guest perhaps?
> 
> Sorry I don't understand what you mean here.

"gfx_passthru" is a generically named option, but it is being
implemented in an IGD specific way. We need to consider the possibility
of other graphics devices needing special handling in the future and
plan accordingly such that we can try and maintain our API guarantees
when this happens.

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.
      * Make libxl detect the type of graphics device somehow and
        therefore automatically determine when gfx_passthru=1 =>
        igd-passthru

>  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?

> > 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?).

>  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
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.

Ian.


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