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

[Jason Andryuk <jandryuk@gmail.com>]

On Fri, Apr 1, 2022 at 9:41 AM Chuck Zmudzinski <brchuckz@netscape.net> wrote:
>
> On 4/1/22 9:21 AM, Chuck Zmudzinski wrote:
> > On 3/30/22 2:45 PM, Jason Andryuk wrote:
> >> On Fri, Mar 18, 2022 at 4:13 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>> On 14.03.2022 04:41, Chuck Zmudzinski wrote:
> >>>> When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
> >>>> opregion to the guest but libxl does not grant the guest permission to
> >>>> access the mapped memory region. This results in a crash of the
> >>>> i915.ko
> >>>> kernel module in a Linux HVM guest when it needs to access the IGD
> >>>> opregion:
> >>>>
> >>>> Oct 23 11:36:33 domU kernel: Call Trace:
> >>>> Oct 23 11:36:33 domU kernel:  ? idr_alloc+0x39/0x70
> >>>> Oct 23 11:36:33 domU kernel: drm_get_last_vbltimestamp+0xaa/0xc0 [drm]
> >>>> Oct 23 11:36:33 domU kernel: drm_reset_vblank_timestamp+0x5b/0xd0
> >>>> [drm]
> >>>> Oct 23 11:36:33 domU kernel:  drm_crtc_vblank_on+0x7b/0x130 [drm]
> >>>> Oct 23 11:36:33 domU kernel:
> >>>> intel_modeset_setup_hw_state+0xbd4/0x1900 [i915]
> >>>> Oct 23 11:36:33 domU kernel:  ? _cond_resched+0x16/0x40
> >>>> Oct 23 11:36:33 domU kernel:  ? ww_mutex_lock+0x15/0x80
> >>>> Oct 23 11:36:33 domU kernel: intel_modeset_init_nogem+0x867/0x1d30
> >>>> [i915]
> >>>> Oct 23 11:36:33 domU kernel:  ? gen6_write32+0x4b/0x1c0 [i915]
> >>>> Oct 23 11:36:33 domU kernel:  ? intel_irq_postinstall+0xb9/0x670
> >>>> [i915]
> >>>> Oct 23 11:36:33 domU kernel:  i915_driver_probe+0x5c2/0xc90 [i915]
> >>>> Oct 23 11:36:33 domU kernel:  ?
> >>>> vga_switcheroo_client_probe_defer+0x1f/0x40
> >>>> Oct 23 11:36:33 domU kernel:  ? i915_pci_probe+0x3f/0x150 [i915]
> >>>> Oct 23 11:36:33 domU kernel:  local_pci_probe+0x42/0x80
> >>>> Oct 23 11:36:33 domU kernel:  ? _cond_resched+0x16/0x40
> >>>> Oct 23 11:36:33 domU kernel:  pci_device_probe+0xfd/0x1b0
> >>>> Oct 23 11:36:33 domU kernel:  really_probe+0x222/0x480
> >>>> Oct 23 11:36:33 domU kernel:  driver_probe_device+0xe1/0x150
> >>>> Oct 23 11:36:33 domU kernel:  device_driver_attach+0xa1/0xb0
> >>>> Oct 23 11:36:33 domU kernel:  __driver_attach+0x8a/0x150
> >>>> Oct 23 11:36:33 domU kernel:  ? device_driver_attach+0xb0/0xb0
> >>>> Oct 23 11:36:33 domU kernel:  ? device_driver_attach+0xb0/0xb0
> >>>> Oct 23 11:36:33 domU kernel:  bus_for_each_dev+0x78/0xc0
> >>>> Oct 23 11:36:33 domU kernel:  bus_add_driver+0x12b/0x1e0
> >>>> Oct 23 11:36:33 domU kernel:  driver_register+0x8b/0xe0
> >>>> Oct 23 11:36:33 domU kernel:  ? 0xffffffffc06b8000
> >>>> Oct 23 11:36:33 domU kernel:  i915_init+0x5d/0x70 [i915]
> >>>> Oct 23 11:36:33 domU kernel:  do_one_initcall+0x44/0x1d0
> >>>> Oct 23 11:36:33 domU kernel:  ? do_init_module+0x23/0x260
> >>>> Oct 23 11:36:33 domU kernel:  ? kmem_cache_alloc_trace+0xf5/0x200
> >>>> Oct 23 11:36:33 domU kernel:  do_init_module+0x5c/0x260
> >>>> Oct 23 11:36:33 domU kernel: __do_sys_finit_module+0xb1/0x110
> >>>> Oct 23 11:36:33 domU kernel:  do_syscall_64+0x33/0x80
> >>>> Oct 23 11:36:33 domU kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> The call trace alone leaves open where exactly the crash occurred.
> >>> Looking at 5.17 I notice that the first thing the driver does
> >>> after mapping the range it to check the signature (both in
> >>> intel_opregion_setup()). As the signature can't possibly match
> >>> with no access granted to the underlying mappings, there shouldn't
> >>> be any further attempts to use the region in the driver; if there
> >>> are, I'd view this as a driver bug.
> >> Yes.  i915_driver_hw_probe does not check the return value of
> >> intel_opregion_setup(dev_priv) and just continues on.
> >>
> >> Chuck, the attached patch may help if you want to test it.
> >>
> >> Regards,
> >> Jason
> >
> > I tested the patch - it made no noticeable difference.I still
> > get the same crash and call trace with the patch. Actually,
> > the call trace I posted here is only the first of three call
> > traces, and I still see all three call traces with the patch.

Thanks for testing.  Sorry it didn't help.

> It is probably necessary to patch intet_opregion_setup to
> return from it with an error sooner if the goal is to suppress
> the call traces that occur when the driver cannot access
> the opregion.

It looks correct for 5.17 running in your domU.  I thought the
opregion signature check would fail.  A failure in
intel_opregion_setup would percolate up through i915_driver_hw_probe
to i915_driver_probe.  In i915_driver_probe the error should goto
out_cleanup_mmio and skip intel_modeset_init_nogem which is in your
backtrace.

Regards,
Jason