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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Furthermore I've found indications (e.g. in the Core Gen11 doc)
that the register may not hold an address in the first place, but
instead a set of bitfields. I can't help the impression that the
driver would still try to map the range pointed at by the value
(as long as it's non-zero), which would imply unpredictable
behavior.

And then, looking further at intel_opregion_setup(), there's yet
one more memory range which the guest may need access to:
opregion->asle->rvda (or a value derived from it) also is handed
to memremap() under certain conditions.

Jan