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

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

On 2015/2/5 17:52, Ian Campbell wrote:
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


I think there are three ways to achieve that:

        * Make the libxl/xl option something which is not generic e.g.
        * 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 =>

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.

So sounds what you're saying is Xen already have this sort of example in libxl.

   Currently, we have to set
something as follows,


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?

Yes, I can understand what you mean but I need to take close look at exactly what should be done in libxl :)

In high level, this way may come out as follows,

#1 libxl parse 'pci=[]' to get SBDF
#2 Scan SBDF by accessing sysfs to get vendor/device IDs.
#3 If this pair of IDs is identified to our target device, IGD, "igd-passthru" would be delivered to qemu.


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.


Thanks for your kind discussion.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.