[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |