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

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

On 3/11/2022 3:09 AM, Jan Beulich wrote:
> 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
After resolving the question of two vs. three pages, I will follow
the process for submitting a patch against the latest staging.

Qubes OS has a patch that uses three pages, and the
igd.c pci file in Qemu's hw/vfio directory also specifies
three pages, but if two is enough, that seems to be safer.
I haven't checked yet to see if there is an official specification
from Intel. I will start by looking in the Linux kernel i915
driver code which might give a clue.

Chuck