[PATCH v2] vfio/igd: Add device ID support for Meteor Lake and Arrow Lake

[PATCH v2] vfio/igd: Add device ID support for Meteor Lake and Arrow Lake

[Yuan Wang]

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 <yuan1.wang@intel.com>
---
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;
     }
 
-- 
2.34.1

Re: [PATCH v2] vfio/igd: Add device ID support for Meteor Lake and Arrow Lake

[Cédric Le Goater]

On 8/25/26 11: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 <yuan1.wang@intel.com>
> ---
> 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;
>       }
>   

Reviewed-by: Cédric Le Goater <clg@redhat.com>

Thanks,

C.

Re: [PATCH v2] vfio/igd: Add device ID support for Meteor Lake and Arrow Lake

[Tomita Moeko]

Reviewed-by: Tomita Moeko <tomitamoeko@gmail.com>

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 <yuan1.wang@intel.com>
> ---
> 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;
>      }
>  

Re: [PATCH v2] vfio/igd: Add device ID support for Meteor Lake and Arrow Lake

[Tomita Moeko]

On 2026-09-08 13:09, Tomita Moeko wrote:
> Reviewed-by: Tomita Moeko <tomitamoeko@gmail.com>

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 <yuan1.wang@intel.com>
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;
>>      }
>>  
> 

Re: [PATCH v2] vfio/igd: Add device ID support for Meteor Lake and Arrow Lake

[Wang, Yuan1]

Hi Moeko

Thanks for the kind review.

On 9/8/2026 5:09 PM, Tomita Moeko wrote:
> 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/
Correct. The BDSM register at PCIe config space offsets 0x5C/0xC0 has
been removed on Meteor Lake and Arrow Lake.
> 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 Meteor Lake and Arrow Lake, BDSM is still present and located in the
MMIO space at offset 0x1080C0 of BAR0. 

The GOP driver continues to read this register to obtain the stolen
memory base address.

And for MTL, there is a WA which there in Linux Gfx driver which cause
it to read 0x1080c0.
Please check the following function i915_direct_stolen_access().

drivers/gpu/drm/i915/i915_utils.c: i915_direct_stolen_access()
bool i915_direct_stolen_access(struct drm_i915_private *i915)
{
    /*
     * Wa_22018444074
     *
     * Access via BAR can hang MTL, go directly to GSM/DSM,
     * except for VM guests which won't have access to it.
     *
     * Normally this would not work but on MTL the system firmware
     * should have relaxed the access permissions sufficiently.
     * 0x138914==0x1 indicates that the firmware has done its job.
     */
    return IS_METEORLAKE(i915) && !i915_run_as_guest() &&
!IS_SRIOV_VF(i915) &&
        intel_uncore_read(&i915->uncore, MTL_PCODE_STOLEN_ACCESS) ==
STOLEN_ACCESS_ALLOWED;
}

Consequently, MTL still needs to read BDSM to obtain the DSM base
address in i915_gem_stolen_lmem_setup() function.
As seen in i915_direct_stolen_access(), this bypass logic only applies
to the bare-metal environment (it falls back for VMs).
However, the GOP driver does not differentiate between bare-metal and
virtualized environments, so we still have to provide a valid BDSM value
to it in GOP driver.

> 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.
The MTL GOP driver always attempts to read from the BDSM register, so a
valid BDSM base address and size must be provided.

Thanks

Yuan