[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 etc. Yeah. 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) Understood. * Make libxl detect the type of graphics device somehow and therefore automatically determine when gfx_passthru=1 => igd-passthruThis 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, 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? 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. Right? 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 thatNo. 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, Thanks for your kind discussion. Tiejun _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |