vmm: ppt: Do not reset an Intel integrated GPU

[wanpengqian_gmail.com]

Summary

ppt_pci_reset() issues an FLR with force=true at every assignment and
unassignment. An Intel integrated GPU whose display engine is scanning
out at that moment (the firmware's framebuffer at the first assignment
after boot, or the host console on efifb) does not go idle: pcie_flr()
prints "Transactions pending after FLR!" and the GPU keeps fetching with
its configuration reset underneath it, still in the host's IOMMU domain
(iommu_add_device() comes after the reset). Moments later other host
devices find their DMA structures overwritten: on a ThinkPad X1 Carbon
gen 6 (i5-8250U, UHD 620) the host's xHCI halted and the NVMe controller
went into fatal status with "Received Master Abort" set on both, 2 s
after the guest got the GPU, and once a page of a file being written was
replaced by the contents of unrelated kernel memory. With the same
build and guest configuration, the reset path crashed 4 times in 16
cold boots (rounds 6, 1, 7 and 2 of four runs) and the patched path 0
times in 20 (plus 0 in 60 earlier boots without the reset); no VT-d
fault was recorded and the IOMMU tables were verified intact at the
panic, so this is the device, not the IOMMU. Reading the GPU's config
space 100 ms after the FLR gave all ones (GGC, BDSM, command register):
the device had dropped off the bus, so pci_restore_state() was lost
too, and it came back with reset configuration while still scanning
out.

Nobody can turn the display off first without a host driver, so do not
reset the IGD at all; the guest's driver initializes it anyway. The
guest-requested FLR path (ppt_reset_device) is left as it is: there the guest's driver asked for the
reset after quiescing the device, and the GPU is in the guest's domain.

Signed-off-by: Wanpeng Qian <[e-mail]>
Sponsored by: keelos.dev

Test Plan

Host: ThinkPad X1 Carbon gen 6 (i5-8250U, UHD 620, PCH xHCI and NVMe), keelOS on a FreeBSD stable/15 base with this change ported to it; guest: Windows 10 with the iGPU and the xHCI controller passed through, started automatically after every firmware cold boot, so the GPU is assigned while it still scans out the firmware framebuffer.

A/B with the same build, the same guest configuration and a loop of firmware cold boots:

• reset path (ppt_pci_reset unchanged): 4 host crashes in 16 cold boots (rounds 6, 1, 7 and 2 of four runs). Each time pcie_flr() logged "Transactions pending after FLR!", about 2 s later xhci0 halted and nvme0 went to fatal status with Received Master Abort set, then the host panicked.
• no reset of the IGD (this change): 0 crashes in 20 cold boots, plus 0 in 60 earlier boots. No "Transactions pending" message; the guest's driver initializes the GPU and the display works as before.

The IOMMU tables were checked at the crash and were intact, and no VT-d fault was recorded, so the corruption comes from the device's DMA, not from a translation error. The guest-requested reset (ppt_reset_device) is not changed and still works for the guest.

Compile-tested on main (405dd8df1 = main + this commit): sys/modules/vmm with -Werror, 0 warnings.

[wanpengqian_gmail.com]

Move the comment to the early return in ppt_pci_reset() and drop the Linux/QEMU remark from comment and summary.