On 2018.04.19 10:40:18 +0200, Gerd Hoffmann wrote: > Hi, > > > 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=auto 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). > > 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. > > 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. > > > 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! > > 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. > > 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) > > Oops. I've trapped into the kvm issue too. Wondering what the reason > is, shouldn't this work with tcg too? > > 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. > > > 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. > > 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. > > 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. > > > anything other than mdev. This inconsistency with physically assigned > > devices has been one of my arguments against enhancing mdev sysfs. > > > > 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, > > Well, no good idea for the physical assigned device case. > > cheers, > Gerd > > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
