On 2026-09-08 13:09, Tomita Moeko wrote: > Reviewed-by: Tomita Moeko <[email protected]>
Sorry I'd like to withdraw this Reviewed-by... > Thank you for your contribution! > > On 2026-08-25 17:04, Yuan Wang wrote: >> Currently, igd_gen() does not include the PCI device IDs for Meteor >> Lake and Arrow Lake platforms, causing it to return -1 for these GPUs. >> >> As a result, QEMU calculates the stolen memory size as 0 and exposes a >> zero-sized 'etc/igd-bdsm-size' entry via fw_cfg. When OVMF boots, >> IgdAssignmentDxe fails validation on the zero BDSM size and aborts >> without programming the ASLS register. Consequently, the guest Intel >> GOP driver fails to locate and read the OpRegion (ASLS remains 0x0). >> >> Add the device ID prefixes (0x7D00 and 0xB600) to igd_gen() as Gen 12 >> so that stolen memory is correctly determined, allowing OVMF to properly >> initialize the OpRegion and BDSM for the Intel GOP driver. >> >> Signed-off-by: Yuan Wang <[email protected]> I took a deeper look about the change, this change actually changes vfio_probe_igd_bar0_quirk() to go with the 64-bit emulated BDSM register path, right? But the problem is, does the BDSM register really exists on Meteor/Arrow Lake and later iGPUs? In drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c:xe_ttm_stolen_mgr_init() if (IS_SRIOV_VF(xe)) stolen_size = 0; else if (IS_DGFX(xe)) stolen_size = detect_bar2_dgfx(xe, mgr); else if (GRAPHICS_VERx100(xe) >= 1270) // MTL+ stolen_size = detect_bar2_integrated(xe, mgr); else stolen_size = detect_stolen(xe, mgr); For Meteor Lake and later, detect_bar2_integrated() is called. The DSM region used is at (BAR2 + 8M). /* * Graphics >= 1270 uses the offset to the GSMBASE as address in the * PTEs, together with the DM flag being set. Previously there was no * such flag so the address was the io_base. * * DSMBASE = GSMBASE + 8MB */ mgr->stolen_base = SZ_8M; mgr->io_base = pci_resource_start(pdev, 2) + mgr->stolen_base; drivers/gpu/drm/i915/gem/i915_gem_stolen.c:i915_gem_stolen_lmem_setup() also suggests it is (BAR2 + 8M) on MTL (i915 only supports up to MTL) if (HAS_LMEMBAR_SMEM_STOLEN(i915)) { // Only True for MTL /* * MTL dsm size is in GGC register. * Also MTL uses offset to GSMBASE in ptes, so i915 * uses dsm_base = 8MBs to setup stolen region, since * DSMBASE = GSMBASE + 8MB. */ ret = mtl_get_gms_size(uncore); if (ret < 0) { drm_err(&i915->drm, "invalid MTL GGC register setting\n"); return ERR_PTR(ret); } dsm_base = SZ_8M; dsm_size = (resource_size_t)(ret * SZ_1M); GEM_BUG_ON(pci_resource_len(pdev, GEN12_LMEM_BAR) != SZ_256M); GEM_BUG_ON((dsm_base + dsm_size) > lmem_size); } else { ... } if (i915_direct_stolen_access(i915)) { ... } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) { ... } else { // MTL io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + dsm_base; io_size = dsm_size; } In addition, nothing about the BDSM register can be found in MTL datasheet vol2, neither 32-bit 0x5C nor 64-bit 0xC0. I believed it is removed since Meteor Lake. https://edc.intel.com/content/www/us/en/design/publications/14th-generation-core-processors-cfg-and-mem-registers/d2-f0-processor-graphics-registers/ Since you are probably an intel employee (from your mail address), you may check the GOP driver code to see if the BDSM register (0x5C/0xC0 in config space and 0x1080C0 in BAR0) is really used or not. Please kindly correct me if I am wrong. For the "IgdAssignmentDxe fails validation on the zero BDSM size and aborts without programming the ASLS register", having a fix skipping BDSM size check on Meteor Lake and later ones could make it work? OpRegion is automatically detected and exposed to guest on IGD as I remember. Thanks, Moeko >> --- >> v2: >> - Resending because the v1 patch was sent with an incorrect future >> system timestamp due to an unsynchronized local clock. No code >> changes. >> --- >> hw/vfio/igd.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c >> index 413a49aae9..a0b6b34d81 100644 >> --- a/hw/vfio/igd.c >> +++ b/hw/vfio/igd.c >> @@ -96,6 +96,8 @@ static int igd_gen(VFIOPCIDevice *vdev) >> case 0x4C00: /* Rocket Lake */ >> case 0x4600: /* Alder Lake */ >> case 0xA700: /* Raptor Lake */ >> + case 0x7D00: /* Meteor Lake / Arrow Lake */ >> + case 0xB600: /* Arrow Lake */ >> return 12; >> } >> >
