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
