Re: BUG: libxenlight fails to grant permission to access Intel IGD Opregion

[Jan Beulich <jbeulich@suse.com>]

On 11.03.2022 06:01, Chuck Zmudzinski wrote:
> Further research showed that these two pages at 0xcc490 are for the
> Intel IGD opregion, and because this memory is not permitted to be
> accessed by the domain, the passthrough of an Intel IGD to a Linux
> HVM domain fails, causing a crash of the Linux i915.ko kernel module
> in the HVM domain. My testing, which was on a desktop with a Haswell
> Intel CPU/IGD, confirmed that these two extra pages need to be
> permitted in order for passthrough of the Intel IGD to a Linux
> domain to work properly.
> 
> I find that adding two pages is enough to fix the problem, but I
> have read in other places that the Opregion is actually three pages,
> and maybe newer revisions of the Intel IGD do need three pages instead
> of two. I am testing on a Haswell Intel chip, which is over 8 years old
> now. So the patch I propose adds two pages, but I am not sure if
> it should be three pages for newer Intel chips.
> 
> The failure to map this memory with gfx_passthru enabled
> is therefore a bug, a regression that was introduced with the two
> aforementioned patches way back in 2014 when Xen 4.5 was under
> development.

Thanks for this analysis. It looks quite plausible (but the question
of 2 vs 3 pages of course needs resolving).

> Once I developed a patch, I did more testing with the traditional
> Qemu device model and Debian's package of Xen-4.16 for Debian
> sid/unstable after I discovered where this bug first appeared in
> Xen 4.5-unstable back in 2014. In my testing, Windows HVM domains are
> not affected by this bug and they function properly, most likely
> because proprietary Intel graphics drivers for Windows are more
> forgiving than the Linux open source drivers for Intel graphics
> regarding the details of how Xen and Qemu configure the domain.
> 
> This bug still exists in current supported versions of Xen
> because in Xen 4.16, passthrough of my Haswell Intel IGD to a Linux
> domain still fails with a crash of the i915 Linux kernel module in
> the Linux unprivileged domain when the traditional Qemu device model
> is used in dom0. The patch at the end of this message fixes it.
> 
> I have not yet succeeded in reproducing this bug with the
> upstream device model because there is another bug in Qemu
> upstream that breaks passthrough of the Intel IGD to a Linux HVM
> domU, so for now, to reproduce it, please use the traditional device
> model.
> 
> Also, as a starting point to reproduce the bug, first get Intel IGD
> passthrough to a Windows HVM domain using the Qemu traditional
> device model working on Xen 4.16. Then replace the Windows HVM domain
> with a Linux HVM domain, keeping everything else the same including
> the Qemu traditional device model. I tested using a Debian 11.2
> (bullseye) HVM domain and Debian sid/unstable with Xen 4.16 and
> a build of the Qemu traditional device model from source as
> provided on xenbits.xen.org
> 
> I am using a desktop computer and the xl toolstack and Xen as
> packaged by Debian, except that I added the traditional device
> model that Debian does not provide.
> 
> If you need more info, please let me know. I am not subscribed to
> xen-devel so please cc me with your replies.
> 
> Regards,
> 
> Chuck
> 
> Here is the patch that fixes the bug on Debian sid/Xen 4.16:

As to an actual patch for us to take - please see
docs/process/sending-patches.pandoc for the formal requirements.
(Note this was recently introduced, so you won't find it in the
4.16 sources. But your patch wants to be against latest staging
anyway.)

Jan