From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJXJG-00019l-2t for qemu-devel@nongnu.org; Thu, 05 Feb 2015 20:02:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJXJC-0000Ha-TZ for qemu-devel@nongnu.org; Thu, 05 Feb 2015 20:02:14 -0500 Received: from mga14.intel.com ([192.55.52.115]:18500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJXJC-0000BX-Mb for qemu-devel@nongnu.org; Thu, 05 Feb 2015 20:02:10 -0500 Message-ID: <54D41274.9090400@intel.com> Date: Fri, 06 Feb 2015 09:01:40 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <1422839843-25622-1-git-send-email-tiejun.chen@intel.com> <20150202121940.GA28773@zion.uk.xensource.com> <21711.29549.892862.333392@mariner.uk.xensource.com> <54D01EAB.1020005@intel.com> <1422961628.9323.32.camel@citrix.com> <54D1770C.4020904@intel.com> <1423046493.17711.28.camel@citrix.com> <54D2C5E5.40407@intel.com> <1423129922.24924.46.camel@citrix.com> In-Reply-To: <1423129922.24924.46.camel@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Campbell Cc: Wei Liu , Ian Jackson , qemu-devel@nongnu.org, xen-devel@lists.xen.org, stefano.stabellini@citrix.com, kraxel@redhat.com 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-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. 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 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, Thanks for your kind discussion. Tiejun