From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhenyu Wang Subject: Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices. Date: Thu, 19 Apr 2018 18:03:47 +0800 Message-ID: <20180419100347.g5tmccydcxl6hetu@zhen-hp.sh.intel.com> References: <20180409103513.8020-1-kraxel@redhat.com> <20180418123153.0f4f037d@w520.home> <20180419084018.dnemdfl4fysg7gkj@sirius.home.kraxel.org> Reply-To: Zhenyu Wang Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2089227054356150934==" Cc: kvm@vger.kernel.org, Erik Skultety , libvirt , kwankhede@nvidia.com, Tina Zhang , intel-gvt-dev@lists.freedesktop.org To: Gerd Hoffmann Return-path: In-Reply-To: <20180419084018.dnemdfl4fysg7gkj@sirius.home.kraxel.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com List-Id: kvm.vger.kernel.org --===============2089227054356150934== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vdjcb6z7v6rz5mjk" Content-Disposition: inline --vdjcb6z7v6rz5mjk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018.04.19 10:40:18 +0200, Gerd Hoffmann wrote: > Hi, >=20 > > Erik Skultety brought up a good question today regarding how libvirt is > > meant to handle these different flavors of display interfaces and > > knowing whether a given mdev device has display support at all. It > > seems that we cannot simply use the default display=3Dauto because > > libvirt needs to specifically configure gl support for a dmabuf type > > interface versus not having such a requirement for a region interface, > > perhaps even removing the emulated graphics in some cases (though I > > don't think we have boot graphics through either solution yet). >=20 > Correct, no boot graphics yet. The option to disable emulated graphics > should be added nevertheless. It's an option after all, you don't have > to use it. >=20 > But after install things usually work just fine, it just takes a little > longer for the guest display to show up.. There is also the option to > add a serial console to the guest for boot loader access. >=20 > > Additionally, GVT-g seems to need the x-igd-opregion support > > enabled(?), which is a non-starter for libvirt as it's an experimental > > option! >=20 > Windows guests need it, yes. And it seems we have still have to add igd > opregion support to ovmf as only bios guests are working. Or hack up a > efi rom doing that. But patching ovmf is probably alot easier because > it already has support code for fw_cfg access. >=20 > Linux i915.ko is happy without opregion. > yeah, that's true. > > So I was ready to return and suggest that maybe libvirt should probe > > the device to know about these ancillary configuration details, but > > then I remembered that both mdev vGPU vendors had external dependencies > > to even allow probing the device. KVMGT will fail to open the device > > if it's not associated with an instance of KVM and NVIDIA vGPU, I > > believe, will fail if the vGPU manager process cannot find the QEMU > > instance to extract the VM UUID. (Both of these were bad ideas) >=20 > Oops. I've trapped into the kvm issue too. Wondering what the reason > is, shouldn't this work with tcg too? >=20 > But, yes, that indeed pretty much kills the "just let libvirt use the > probe ioctl" idea. I also don't like that strict link and although now KVM is the only upstream hypervisor GVT supports, we shouldn't require a must available instance for some device info access. >=20 > > The existing device_api file reports "vfio-pci", so we base the device > > API info in a directory named vfio-pci. We're specifically exposing > > device information, so we have a device directory. We have a GFX_PLANE > > query ioctl, so we have a gfx_plane sub-directory. I imagine the > > dmabuf and region files here expose either Y/N or 1/0. >=20 > Do we want tie this to vfio-pci? All existing devices are actually pci, > and the qemu code only works for vfio-pci devices too. But at vfio api > level there is no vfio-pci dependency I'm aware of, and I think we > shouldn't add one without a good reason. >=20 > Should we just add a gfx_plane_api file maybe? Which would be a > comma-separated list of interfaces, listed in order of preference in > case multiple are supported. Or a 'feature' file with defined string list for those capabilities? Might be easier to extend in future. >=20 > > anything other than mdev. This inconsistency with physically assigned > > devices has been one of my arguments against enhancing mdev sysfs. > >=20 > > Thanks to anyone still reading this. Ideas how we might help libvirt > > fill this information void so that they can actually configure a VM > > with a display device? Thanks, >=20 > Well, no good idea for the physical assigned device case. >=20 > cheers, > Gerd >=20 > PS: Any comment on the sample driver patches? Or should I take the lack > of comments as "no news is good news, they are queued up already"? > _______________________________________________ > intel-gvt-dev mailing list > intel-gvt-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev --=20 Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 --vdjcb6z7v6rz5mjk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTXuabgHDW6LPt9CICxBBozTXgYJwUCWthpgwAKCRCxBBozTXgY J8idAKCHIECUpT2QEUb78VQ83rV5DoQ3/gCfaRlmjl31IWWwCAhWj06GhbfMh8E= =92Pw -----END PGP SIGNATURE----- --vdjcb6z7v6rz5mjk-- --===============2089227054356150934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2089227054356150934==--