Discussion about x-igd-opregion

[Alex Williamson]

[CC +Laszlo, Gerd, Jack]

On Thu, 26 Apr 2018 05:56:54 +0000
"Zhang, Tina" <tina.zhang at intel.com> wrote:

> + intel-gvt-dev at lists.freedesktop.org
> 
> From: Zhang, Tina
> Sent: Thursday, April 26, 2018 1:54 PM
> To: 'Alex Williamson' <alex.williamson at redhat.com>
> Cc: Lv, Zhiyuan <zhiyuan.lv at intel.com>; Yuan, Hang <hang.yuan at intel.com>; Tian, Kevin <kevin.tian at intel.com>; Wang, Zhenyu Z <zhenyu.z.wang at intel.com>; Wang, Zhi A <zhi.a.wang at intel.com>; Zhang, Xiong Y <xiong.y.zhang at intel.com>; Du, Changbin <changbin.du at intel.com>
> Subject: Discussion about x-igd-opregion
> 
> Hi Alex,
> 
> These days, more and more people are asking if it's possible to let GVT-g support dma-buf feature with OVMF. As we know that, simply enabling the BDSM fw_cfg entry in OVMF cannot solve the whole problem, as we are still basing on "x-igd-opregion=on" which is an experimental option. So, we'd like to use this thread to discuss the issue and find a solution for it.
> 
> Background:
> The problem is in GVT-g, Windows guest needs opregion to touch display registers, which is key to GVT-g dma-buf display feature based on VFIO. This opregion is provided by an QEMU experimental option called "x-igd-opregion=on", which was introduced due to some interesting display usages for IGD UPT mode. But the UPT mode isn't invented to be used with display. That's why this opinion is called experimental x-option.
> 
> So, Alex, we saw that you have some comments about this issue before: "The feature cannot be considered supportable in libvirt until opregion support is either enabled automatically or enabled through a non-experimental option". Could you elaborate more on these two opinions?
> 
> We'd like to propose a solution to solve this issue between QEMU/VFIO and GVT-g. After all, as you know, it's not reasonable to let OVMF support opregion only for IGD UPT mode, as the legacy mode is missing and the UPT mode isn't defined to work with the help of a firmware.

Hi Tina,

To further elaborate, requiring the VM to run with an experimental
(read unsupported) option is not a valid solution, nor do I think that
this experimental option can or should be promoted to a supported
option.  Until we have a supportable solution for enabling opregion
support in QEMU, I don't think it's valid to ask other projects to
support it.

Note that with IGD legacy assignment, we don't require any specific
libvirt support, configuring a compatible VM topology is sufficient for
enabling these features.  Thus we have a supportable mechanism for
creating the VM and reasonably reliable support that we can enable
fw_cfg options in SeaBIOS and assume the burden of support for those
options.

I would take the same approach here.  Libvirt has absolutely no
interest in identifying GVT-g configurations requiring a device
specific feature in QEMU, nor should they, nor perhaps can they.  For
instance if igd-opregion=on were a supported vfio-pci QEMU option, can
a user definitively know when it's considered valid to apply it?  Can it
be fully documented?  Can we expect that level understanding by a user,
or even programatically in libvirt?  I don't think so.

So the first step is that QEMU needs to determine how to automatically
enable opregion support for the desired configurations.  Perhaps that's
as simple as "if we're enabling a display through vfio on an Intel
graphics class device and the device includes an igd-opregion region,
enable opregion support".  Once we achieve that step, then we remove any
device specific option requirements from libvirt, it no longer matters
that the user exposed vfio-pci device option is experimental.  A
prerequisite here however is that the automatic selection must be the
correct option for *all* guests.  IGD has a habit of behaving
differently depending on the guest OS and drivers, which is not
something that QEMU has the option of knowing in advance.

From there, it's already been proposed that a GVT-g device could expose
a UEFI compatible option ROM that could potentially enable the opregion
on its own, which seems like a better option to pursue before we ask
EDK2 to incorporate opregion handling.  Thanks,

Alex