Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

On 4/6/22 9:10 AM, Jason Andryuk wrote:
> On Tue, Apr 5, 2022 at 9:31 PM Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx> wrote:
> > Correction (sorry for the confusion):
> >
> > I didn't know I needed to replace more than just a
> > re-built i915.ko module to enable the patch
> > for testing. When I updated the entire Debian kernel
> > package including all the modules and the kernel
> > image with the patched kernel package, it made
> > quite a difference.
> >
> > With Jason's patch, the three call traces just became a
> > much shorter error message:
> >
> > Apr 05 20:46:18 debian kernel: xen: --> pirq=16 -> irq=24 (gsi=24)
> > Apr 05 20:46:18 debian kernel: i915 0000:00:02.0: [drm] VT-d active for
> > gfx access
> > Apr 05 20:46:18 debian kernel: i915 0000:00:02.0: vgaarb: deactivate vga
> > console
> > Apr 05 20:46:18 debian kernel: Console: switching to colour dummy device
> > 80x25
> > Apr 05 20:46:18 debian kernel: i915 0000:00:02.0: [drm] DMAR active,
> > disabling use of stolen memory
> > Apr 05 20:46:18 debian kernel: resource sanity check: requesting [mem
> > 0xffffffff-0x100001ffe], which spans more than Reserved [mem
> > 0xfdfff000-0xffffffff]
> > Apr 05 20:46:18 debian kernel: caller memremap+0xeb/0x1c0 mapping
> > multiple BARs
> > Apr 05 20:46:18 debian kernel: i915 0000:00:02.0: Device initialization
> > failed (-22)
> > Apr 05 20:46:18 debian kernel: i915 0000:00:02.0: Please file a bug on
> > drm/i915; see
> > https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
> > for details.
> > Apr 05 20:46:18 debian kernel: i915: probe of 0000:00:02.0 failed with
> > error -22
> > --------------------- End of Kernel Error Log ----------------------
> >
> > So I think the patch does propagate the error up the
> > stack and bails out before producing the Call traces,
> Thanks for re-testing.
>
> I'm a little surprised you still had output from the VM & display with
> the i915 driver not binding.  I guess Linux fell back to another VGA
> or Framebuffer driver for the display.
By looking at journal entries in the guest, it is clear the Xorg
driver fell back from the kms modesetting driver to the vesa
driver, as shown by the following journal entries.

When guest can access opregion gdm:

Apr 05 20:42:45 debian /usr/libexec/gdm-x-session[1226]: (II) modeset(0):
 Serial No: LX1AA0044210
Apr 05 20:42:45 debian /usr/libexec/gdm-x-session[1226]: (II) modeset(0)
: Monitor name: Acer H236HL

When guest cannot access opregion:

Apr 05 20:46:22 debian /usr/libexec/gdm-x-session[1164]: (II) VESA(0):
 Serial No: LX1AA0044210
Apr 05 20:46:22 debian /usr/libexec/gdm-x-session[1164]: (II) VESA(0):
 Monitor name: Acer H236HL

But as I said when I tried to login to a Gnome session,
the system hung, and there are no journal entries captured
in either the Dom0 or the guest, so it is hard to tell what
happened. I think maybe the full Gnome session, as opposed
to the gdm3 display manager, did not fall back to the Xorg
vesa driver and when it tried to use the Xorg modesetting
driver it caused the system to hang because the modesetting
driver uses KMS and probably tried to use the i915 module
which was not initialized correctly due to the inability to
access the opregion.

I also noted in an earlier message in this thread that when
the guest cannot access the opregion, the guest overwrites
the register that contains the mapped opregion address for
the guest, which is provided for the guest by the Qemu
device model, with the invalid value of 0xffffffff.

When the gnome session manager started the session, it
apparently caused the i915 module to try to access the
opregion at the invalid address 0xffffffff and thus caused
the system to hang, as shown in the journal entry I posted
yesterday:

Apr 05 20:46:18 debian kernel: resource sanity check: requesting
[mem 0xffffffff-0x100001ffe], which spans more than Reserved
[mem 0xfdfff000-0xffffffff]

This is a request by the guest for 2 pages, which is the
size of the opregion, but it is using the invalid address
0xffffffff for the opregion address. So although this resource
sanity check failed, the system still hung later on when the
user tried to login to the gnome session.

Regards,

Chuck