On Mon, 14 Sep 2026 16:41:58 +0800, Tomita Moeko wrote: > Just curious, on host side, does the value of 0x1080C0 equals (BAR2 + 8M) > on Meteor and Arrow Lake?
No. Measured on Meteor Lake-P (8086:7d55, host i915): BAR2 (LMEMBAR) 0x4000000000, 256MB MMIO 0x108100 GSMBASE 0x70000000 MMIO 0x1080C0 DSMBASE 0x70800000 (GSMBASE + 8MB) MMIO 0x108040 GGC 0x4c0 (GGMS=3, GMS=4 -> 128MB) config 0x50 GGC 0x4c0 config 0x5C 0 config 0xC0-0xC3 MSI Pending Bits (MSI cap at 0xac, 64-bit + PVM) config 0xC4-0xC7 0 MMIO 0x138914 1 /proc/iomem 64000000-787fffff : Reserved DSMBASE is a system physical address inside the BIOS reserved range, and DSMBASE + 128MB is exactly the end of that range. BAR2 + 8M is the aperture onto the same memory: i915_gem_stolen.c and xe_ttm_stolen_mgr.c use either DSMBASE or LMEMBAR + 8M as the io base of the same stolen region. So with igd_gen() == -1, where no BAR0 quirk is installed, a guest reads the host physical DSMBASE from 0x1080C0. Given Yuan's point that the GOP reads this register for its stolen base, that is a host address handed to guest firmware, and something QEMU should fix. > My concern is that if guest driver still uses (BAR2 + 8M) as DSM base, while > 0x1080C0 pointing to the mocked region, will this bring any inconsistency? The drivers map stolen on MTL+ with DM-flagged PTEs as offsets from GSMBASE (xe_ttm_stolen_mgr.c; i915 sets PTE_LM for stolen-local), which a region in guest RAM cannot satisfy. Whether the GOP maps its frame buffer the same way I cannot check from here. Yuan, if the display has come up for you with v2 and the stock GOP, that answers it; the variant below does not depend on the answer. > Having the register pointing to guest's (BAR2 + 8M) sounds more reasonable, > but it would require more efforts, monitoring config space writes to BAR2 and > changing the emulated value in QEMU. Agree with the direction, and it is cheaper than that: a read-only BAR0 quirk can take pci_get_bar_addr(pdev, 2) at read time, returning BAR2 at 0x108100 and BAR2 + 8M at 0x1080C0. Then the CPU-side address resolves to real stolen memory through the aperture instead of guest RAM, bdsm-size stays 0 as documented, and nothing in config space is invented. > Possibly an easier way is emulating MTL_PCODE_STOLEN_ACCESS(0x138914) to > disallowed in QEMU, if the GOP driver code checks it, to enforce the access > via BAR2 in guest. 0x138914 reads 1 on the host and is not quirked, so a guest sees 1 too. Returning 0 there is a small addition and covers a GOP that checks it; the DSMBASE quirk covers one that does not. On the Wa itself: i915 already takes the BAR path in guests (i915_run_as_guest() short-circuits i915_direct_stolen_access()), so that path has upstream precedent; we have not measured whether the hang reproduces there. The firmware still has to program ASLS. The IgdAssignmentDxe build the v2 commit message describes aborts on bdsm-size=0 before doing so; VfioIgdPkg has no such check and programs ASLS for MTL+ as is. I'll write the quirk. It can go into Yuan's v3 or on top of it as a separate patch -- Yuan, your call. Either way it needs a run with the stock GOP build on your setup. Junjie
