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
