From: Matt Roper <matthew.d.roper@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
Michal Wajdeczko <michal.wajdeczko@intel.com>
Subject: Re: [PATCH v4 03/23] drm/xe: Move 'va_bits' flag back to platform descriptor
Date: Tue, 7 Oct 2025 15:44:50 -0700 [thread overview]
Message-ID: <20251007224450.GF5409@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <zovx5tsl5jbxl46r7dd6xhf7o2364fmszcnowp4tyo33zwy4to@akwerhv2x7un>
On Tue, Oct 07, 2025 at 05:02:57PM -0500, Lucas De Marchi wrote:
> On Tue, Oct 07, 2025 at 01:48:33PM -0700, Matt Roper wrote:
> > The number of virtual address bits is something that should be tracked
> > at the platform level rather than the IP level. Even when mixing and
> > matching various graphics, media, and display IP blocks, the platform as
> > a whole has to have consistent page table handling. This is also a
> > trait that should be tied to the platform even if the graphics IP itself
> > is not present (e.g., if we disable the primary GT via configfs).
> >
> > v2:
> > - Drop the default value of 48 and explicitly set it in each relevant
> > descriptor. (Lucas, Michal)
> > v3:
> > - Drop an outdated comment about default value. (Michal)
> >
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_pci.c | 21 +++++++++++++++------
> > drivers/gpu/drm/xe/xe_pci_types.h | 2 +-
> > 2 files changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> > index 3f42b91efa28..69ed987fef67 100644
> > --- a/drivers/gpu/drm/xe/xe_pci.c
> > +++ b/drivers/gpu/drm/xe/xe_pci.c
> > @@ -52,13 +52,11 @@ __diag_ignore_all("-Woverride-init", "Allow field overrides in table");
> > static const struct xe_graphics_desc graphics_xelp = {
> > .hw_engine_mask = BIT(XE_HW_ENGINE_RCS0) | BIT(XE_HW_ENGINE_BCS0),
> >
> > - .va_bits = 48,
> > .vm_max_level = 3,
> > };
> >
> > #define XE_HP_FEATURES \
> > .has_range_tlb_inval = true, \
> > - .va_bits = 48, \
> > .vm_max_level = 3
> >
> > static const struct xe_graphics_desc graphics_xehpg = {
> > @@ -84,7 +82,6 @@ static const struct xe_graphics_desc graphics_xehpc = {
> > BIT(XE_HW_ENGINE_CCS2) | BIT(XE_HW_ENGINE_CCS3),
> >
> > XE_HP_FEATURES,
> > - .va_bits = 57,
> > .vm_max_level = 4,
> > .vram_flags = XE_VRAM_FLAGS_NEED64K,
> >
> > @@ -108,7 +105,6 @@ static const struct xe_graphics_desc graphics_xelpg = {
> > .has_range_tlb_inval = 1, \
> > .has_usm = 1, \
> > .has_64bit_timestamp = 1, \
> > - .va_bits = 48, \
> > .vm_max_level = 4, \
> > .hw_engine_mask = \
> > BIT(XE_HW_ENGINE_RCS0) | \
> > @@ -174,6 +170,7 @@ static const struct xe_device_desc tgl_desc = {
> > .has_sriov = true,
> > .max_gt_per_tile = 1,
> > .require_force_probe = true,
> > + .va_bits = 48,
> > };
> >
> > static const struct xe_device_desc rkl_desc = {
> > @@ -185,6 +182,7 @@ static const struct xe_device_desc rkl_desc = {
> > .has_llc = true,
> > .max_gt_per_tile = 1,
> > .require_force_probe = true,
> > + .va_bits = 48,
> > };
> >
> > static const u16 adls_rpls_ids[] = { INTEL_RPLS_IDS(NOP), 0 };
> > @@ -203,6 +201,7 @@ static const struct xe_device_desc adl_s_desc = {
> > { XE_SUBPLATFORM_ALDERLAKE_S_RPLS, "RPLS", adls_rpls_ids },
> > {},
> > },
> > + .va_bits = 48,
> > };
> >
> > static const u16 adlp_rplu_ids[] = { INTEL_RPLU_IDS(NOP), 0 };
> > @@ -221,6 +220,7 @@ static const struct xe_device_desc adl_p_desc = {
> > { XE_SUBPLATFORM_ALDERLAKE_P_RPLU, "RPLU", adlp_rplu_ids },
> > {},
> > },
> > + .va_bits = 48,
> > };
> >
> > static const struct xe_device_desc adl_n_desc = {
> > @@ -233,6 +233,7 @@ static const struct xe_device_desc adl_n_desc = {
> > .has_sriov = true,
> > .max_gt_per_tile = 1,
> > .require_force_probe = true,
> > + .va_bits = 48,
> > };
> >
> > #define DGFX_FEATURES \
> > @@ -249,6 +250,7 @@ static const struct xe_device_desc dg1_desc = {
> > .has_heci_gscfi = 1,
> > .max_gt_per_tile = 1,
> > .require_force_probe = true,
> > + .va_bits = 48,
> > };
> >
> > static const u16 dg2_g10_ids[] = { INTEL_DG2_G10_IDS(NOP), INTEL_ATS_M150_IDS(NOP), 0 };
> > @@ -265,7 +267,8 @@ static const u16 dg2_g12_ids[] = { INTEL_DG2_G12_IDS(NOP), 0 };
> > { XE_SUBPLATFORM_DG2_G11, "G11", dg2_g11_ids }, \
> > { XE_SUBPLATFORM_DG2_G12, "G12", dg2_g12_ids }, \
> > { } \
> > - }
> > + }, \
> > + .va_bits = 48
> >
> > static const struct xe_device_desc ats_m_desc = {
> > .pre_gmdid_graphics_ip = &graphics_ip_xehpg,
> > @@ -303,6 +306,7 @@ static const __maybe_unused struct xe_device_desc pvc_desc = {
> > .max_gt_per_tile = 1,
> > .max_remote_tiles = 1,
> > .require_force_probe = true,
> > + .va_bits = 57,
> > .has_mbx_power_limits = false,
> > };
> >
> > @@ -314,6 +318,7 @@ static const struct xe_device_desc mtl_desc = {
> > .has_display = true,
> > .has_pxp = true,
> > .max_gt_per_tile = 2,
> > + .va_bits = 48,
> > };
> >
> > static const struct xe_device_desc lnl_desc = {
> > @@ -323,6 +328,7 @@ static const struct xe_device_desc lnl_desc = {
> > .has_pxp = true,
> > .max_gt_per_tile = 2,
> > .needs_scratch = true,
> > + .va_bits = 48,
>
> as a follow up, maybe do a s/dma_mask_size/pa_bits/, so it's easy for
> people enabling new platforms to reference e.g. bspec 70817 where they
> are noted as "Virtual Address Range" and "Physical Address Range".
I'm a little bit hesitant about making that rename, because the reality
is more complicated and confusing than that. For example, bspec 53650
will tell you the physical address range of ADL-S is 46-bits, but we
still need to limit ourselves to 39 bits in the driver. We were
confused during early ADL-S enabling because we thought the 46-bit
address space in the spec meant we should just set the mask size to
46-bits, but that caused a bunch of DMAR faults.
Rodrigo eventually tracked down a hardware architect who gave us some
more insight into what it all means at the platform level. If I
understand correctly, the host physical addresses are indeed 46-bits
when MKTME + IOMMU is in use (HPA[45:42] is a MKTME key ID and
HPA[41:39] is always 0). However that's only really relevant to the
IOMMU and hypervisor in those specific configurations. Guest physical
addresses are still 39-bits, and when MKTME is disabled the platform is
limited to 39-bit addresses.
Basically the real details here wind up being a platform-level thing
that isn't always clearly documented or explained in the bspec. Simply
taking the single value that the bspec calls "physical address range"
(with no other explanation) and plugging that into the driver sometimes
isn't the right thing to do.
dma_mask_size probably isn't the most descriptive structure field name
either, but at least it matches the Linux DMA mapping functions that we
need to call during init.
Matt
>
>
> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
>
> Lucas De Marchi
>
> > };
> >
> > static const struct xe_device_desc bmg_desc = {
> > @@ -338,6 +344,7 @@ static const struct xe_device_desc bmg_desc = {
> > .has_sriov = true,
> > .max_gt_per_tile = 2,
> > .needs_scratch = true,
> > + .va_bits = 48,
> > };
> >
> > static const struct xe_device_desc ptl_desc = {
> > @@ -347,6 +354,7 @@ static const struct xe_device_desc ptl_desc = {
> > .has_sriov = true,
> > .max_gt_per_tile = 2,
> > .needs_scratch = true,
> > + .va_bits = 48,
> > };
> >
> > #undef PLATFORM
> > @@ -584,6 +592,8 @@ static int xe_info_init_early(struct xe_device *xe,
> > subplatform_desc->subplatform : XE_SUBPLATFORM_NONE;
> >
> > xe->info.dma_mask_size = desc->dma_mask_size;
> > + xe->info.va_bits = desc->va_bits;
> > +
> > xe->info.is_dgfx = desc->is_dgfx;
> > xe->info.has_fan_control = desc->has_fan_control;
> > xe->info.has_mbx_power_limits = desc->has_mbx_power_limits;
> > @@ -713,7 +723,6 @@ static int xe_info_init(struct xe_device *xe,
> > }
> >
> > xe->info.vram_flags = graphics_desc->vram_flags;
> > - xe->info.va_bits = graphics_desc->va_bits;
> > xe->info.vm_max_level = graphics_desc->vm_max_level;
> > xe->info.has_asid = graphics_desc->has_asid;
> > xe->info.has_atomic_enable_pte_bit = graphics_desc->has_atomic_enable_pte_bit;
> > diff --git a/drivers/gpu/drm/xe/xe_pci_types.h b/drivers/gpu/drm/xe/xe_pci_types.h
> > index 9b9766a3baa3..796439571abe 100644
> > --- a/drivers/gpu/drm/xe/xe_pci_types.h
> > +++ b/drivers/gpu/drm/xe/xe_pci_types.h
> > @@ -30,6 +30,7 @@ struct xe_device_desc {
> > u8 dma_mask_size;
> > u8 max_remote_tiles:2;
> > u8 max_gt_per_tile:2;
> > + u8 va_bits;
> >
> > u8 require_force_probe:1;
> > u8 is_dgfx:1;
> > @@ -51,7 +52,6 @@ struct xe_device_desc {
> > };
> >
> > struct xe_graphics_desc {
> > - u8 va_bits;
> > u8 vm_max_level;
> > u8 vram_flags;
> >
> > --
> > 2.51.0
> >
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
next prev parent reply other threads:[~2025-10-07 22:45 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 20:48 [PATCH v4 00/23] Allow configfs to disable specific GT type(s) Matt Roper
2025-10-07 20:48 ` [PATCH v4 01/23] drm/xe/huc: Adjust HuC check on primary GT Matt Roper
2025-10-07 20:48 ` [PATCH v4 02/23] drm/xe: Drop GT parameter to xe_display_irq_postinstall() Matt Roper
2025-10-07 20:48 ` [PATCH v4 03/23] drm/xe: Move 'va_bits' flag back to platform descriptor Matt Roper
2025-10-07 22:02 ` Lucas De Marchi
2025-10-07 22:44 ` Matt Roper [this message]
2025-10-07 20:48 ` [PATCH v4 04/23] drm/xe: Move 'vm_max_level' " Matt Roper
2025-10-07 21:54 ` Lucas De Marchi
2025-10-08 13:28 ` Gustavo Sousa
2025-10-07 20:48 ` [PATCH v4 05/23] drm/xe: Move 'vram_flags' " Matt Roper
2025-10-07 20:48 ` [PATCH v4 06/23] drm/xe: Move 'has_flatccs' " Matt Roper
2025-10-10 10:50 ` Jani Nikula
2025-10-13 16:42 ` Matt Roper
2025-10-07 20:48 ` [PATCH v4 07/23] drm/xe: Read VF GMD_ID with a specifically-allocated dummy GT Matt Roper
2025-10-08 3:06 ` Lucas De Marchi
2025-10-07 20:48 ` [PATCH v4 08/23] drm/xe: Move primary GT allocation from xe_tile_init_early to xe_tile_init Matt Roper
2025-10-07 20:48 ` [PATCH v4 09/23] drm/xe: Skip L2 / TDF cache flushes if primary GT is disabled Matt Roper
2025-10-07 20:48 ` [PATCH v4 10/23] drm/xe/query: Report hwconfig size as 0 " Matt Roper
2025-10-07 20:48 ` [PATCH v4 11/23] drm/xe/pmu: Initialize PMU event types based on first available GT Matt Roper
2025-10-07 20:48 ` [PATCH v4 12/23] drm/xe: Check for primary GT before looking up Wa_22019338487 Matt Roper
2025-10-08 13:30 ` Gustavo Sousa
2025-10-07 20:48 ` [PATCH v4 13/23] drm/xe: Make display part of Wa_22019338487 a device workaround Matt Roper
2025-10-07 20:48 ` [PATCH v4 14/23] drm/xe/irq: Don't try to lookup engine masks for non-existent primary GT Matt Roper
2025-10-07 20:48 ` [PATCH v4 15/23] drm/xe: Handle Wa_22010954014 and Wa_14022085890 as device workarounds Matt Roper
2025-10-07 20:48 ` [PATCH v4 16/23] drm/xe/rtp: Pass xe_device parameter to FUNC matches Matt Roper
2025-10-07 20:48 ` [PATCH v4 17/23] drm/xe: Bypass Wa_14018094691 when primary GT is disabled Matt Roper
2025-10-07 20:48 ` [PATCH v4 18/23] drm/xe: Correct lineage for Wa_22014953428 and only check with valid GT Matt Roper
2025-10-07 20:48 ` [PATCH v4 19/23] drm/xe: Check that GT is not NULL before testing Wa_16023588340 Matt Roper
2025-10-07 20:48 ` [PATCH v4 20/23] drm/xe: Don't check BIOS-disabled FlatCCS if primary GT is disabled Matt Roper
2025-10-07 20:48 ` [PATCH v4 21/23] drm/xe: Break GT setup out of xe_info_init() Matt Roper
2025-10-08 3:15 ` Lucas De Marchi
2025-10-08 13:39 ` Gustavo Sousa
2025-10-07 20:48 ` [PATCH v4 22/23] drm/xe/configfs: Add attribute to disable GT types Matt Roper
2025-10-08 3:37 ` Lucas De Marchi
2025-10-08 19:10 ` Matt Roper
2025-10-08 19:22 ` Lucas De Marchi
2025-10-08 10:12 ` Michal Wajdeczko
2025-10-08 20:08 ` Matt Roper
2025-10-08 21:10 ` Lucas De Marchi
2025-10-08 14:06 ` Gustavo Sousa
2025-10-07 20:48 ` [PATCH v4 23/23] drm/xe/sriov: Disable SR-IOV if primary GT is disabled via configfs Matt Roper
2025-10-07 20:56 ` ✗ CI.checkpatch: warning for Allow configfs to disable specific GT type(s) (rev4) Patchwork
2025-10-07 20:57 ` ✓ CI.KUnit: success " Patchwork
2025-10-07 21:49 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-07 23:22 ` ✗ Xe.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251007224450.GF5409@mdroper-desk1.amr.corp.intel.com \
--to=matthew.d.roper@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=michal.wajdeczko@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox