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.
>
> > and...
> >
> > I even had output after booting - the gdm3 Gnome display
> > manager login page displayed, but when I tried to login to
> > the Gnome desktop, the screen went dark and I could
> > not even login to the headless Xen Dom0 control domain
> > via ssh after that and I just used the reset button on the
> > machine to reboot it, so the patch causes some trouble
> > with the Dom0 when the guest cannot access the
> > opregion. The patch works fine when the guest can
> > access the opregion and in that case I was able to
> > login to the Gnome session, but it caused quite a bit of
> > trouble and apparently crashed the Dom0 or at
> > least caused networking in the Dom0 to stop working
> > when I tried to login to the Gnome session in the
> > guest for the case when the guest cannot access
> > the opregion. So I would not recommend Jason's
> > patch as is for the Linux kernel. The main reason
> > is that it looks like it is working at first with a
> > login screen displayed, but when a user tries to login,
> > the whole system crashes.
> 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.
>
> However, locking up the host isn't good.  You didn't happen to catch
> any Xen or dom0 output when that happened?
>
> Regards,
> Jason
I just looked at Dom0's systemd journal and it did not
capture anything. The six minute gap between
Apr 05 20:46 and Apr 05 20:52 which is when I
rebooted Dom0 after the crash is when bad things
happened:

Apr 05 20:46:01 Dom0 kernel: pciback 0000:00:1b.0: xen_pciback: vpci: 
assign to virtual slot 0
Apr 05 20:46:01 Dom0 kernel: pciback 0000:00:1b.0: registering for 18
Apr 05 20:46:01 Dom0 kernel: pciback 0000:00:14.0: xen_pciback: vpci: 
assign to virtual slot 1
Apr 05 20:46:01 Dom0 kernel: pciback 0000:00:14.0: registering for 18
Apr 05 20:46:01 Dom0 kernel: pciback 0000:00:02.0: xen_pciback: vpci: 
assign to virtual slot 2
Apr 05 20:46:01 Dom0 kernel: pciback 0000:00:02.0: registering for 18
Apr 05 20:46:01 Dom0 sudo[9639]: pam_unix(sudo:session): session closed 
for user root
Apr 05 20:46:13 Dom0 sshd[9541]: Received disconnect from <redacted> 
port 60294:11: disconnected by user
Apr 05 20:46:13 Dom0 sshd[9541]: Disconnected from user <redacted> 
<redacted> port 60294
Apr 05 20:46:13 Dom0 sshd[9521]: pam_unix(sshd:session): session closed 
for user <redacted>
Apr 05 20:46:13 Dom0 systemd-logind[497]: Session 27 logged out. Waiting 
for processes to exit.
Apr 05 20:46:17 Dom0 kernel: xen-blkback: backend/vbd/18/51712: using 4 
queues, protocol 1 (x86_64-abi) persistent grants
Apr 05 20:46:17 Dom0 kernel: xen-blkback: backend/vbd/18/51728: using 4 
queues, protocol 1 (x86_64-abi) persistent grants
Apr 05 20:46:17 Dom0 kernel: vif vif-18-0 vif18.0: Guest Rx ready
Apr 05 20:46:17 Dom0 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: 
link becomes ready
Apr 05 20:46:19 Dom0 dhcpd[9852]: DHCPDISCOVER from <redacted> via vif18.0
Apr 05 20:46:19 Dom0 dhcpd[9852]: DHCPOFFER on <redacted> to <redacted> 
via vif18.0
Apr 05 20:46:19 Dom0 dhcpd[9852]: DHCPREQUEST for <redacted> 
(<redacted>) from <redacted> via vif18.0
Apr 05 20:46:19 Dom0 dhcpd[9852]: DHCPACK on <redacted> to <redacted> 
via vif18.0
Apr 05 20:52:34 Dom0 kernel: Linux version 5.16.0-6-amd64 
(debian-kernel@xxxxxxxxxxxxxxxx) (gcc-11 (Debian 11.2.0-19) 11.2.0, GNU 
ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT Debian 5.16.18-1 
(2022-03-29)
Apr 05 20:52:34 Dom0 kernel: Command line: placeholder 
root=/dev/mapper/systems-unstable ro reboot=bios quiet console=hvc0
I would probably need to connect Dom0 to a serial
console to capture something from Dom0 or Xen.
I have done that in the past using a serial cable
connected to a Windows 8 laptop using a usb to
serial adapter I have but last time I tried it the usb
to serial adapter did not work, I think because of
the upgrade of the laptop to Windows 10.

Regards,

Chuck