Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Tomasz Lis <tomasz.lis@intel.com>, <intel-xe@lists.freedesktop.org>
Cc: "Michał Winiarski" <michal.winiarski@intel.com>,
	"Piotr Piórkowski" <piotr.piorkowski@intel.com>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Satyanarayana K V P" <satyanarayana.k.v.p@intel.com>
Subject: Re: [PATCH v4 4/4] drm/xe/vf: Do not disable VF migration on ATS-M
Date: Mon, 20 Oct 2025 23:53:55 +0200	[thread overview]
Message-ID: <ddb0a685-e0fd-428c-b292-7925011d89d8@intel.com> (raw)
In-Reply-To: <20251020205808.1187308-5-tomasz.lis@intel.com>



On 10/20/2025 10:58 PM, Tomasz Lis wrote:
> The ATS-M does support VF migration, and it has graphics ver below
> the currently allowed range. Experimental support of this platform
> should therefore be available.

maybe the wording here should be:

"Our current support for the VF migration depends on the availability
of the MEMIRQ rather than specific graphics version 20."

"Relax our early migration support checks to allow also use some
older platforms like ATS-M for experiments and testing."

> 
> This change allows experimental VF migration support on ATS-M. It
> is also explicitly not allowing ADL, by adding condition on MEMIRQ.
> Supporting VF migration through MMIO interrupts would require
> some special handling in order to achieve reliability.

hmm, but is this something that we still plan to implement?
all official SR-IOV platforms supported by the Xe driver (PTL+) have MEMIRQ

> 
> v2: Add MEMIRQ condition
> 
> v3: Remove platform version check, as only 12+ are supported by Xe
>  driver anyway (Michal)
> 
> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_sriov_vf.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_sriov_vf.c b/drivers/gpu/drm/xe/xe_sriov_vf.c
> index 3a3cd9c35aa8..75760da247f4 100644
> --- a/drivers/gpu/drm/xe/xe_sriov_vf.c
> +++ b/drivers/gpu/drm/xe/xe_sriov_vf.c
> @@ -159,10 +159,8 @@ static void vf_migration_init_early(struct xe_device *xe)
>  		return xe_sriov_vf_migration_disable(xe,
>  				"experimental feature not available on production builds");
>  
> -	if (GRAPHICS_VER(xe) < 20)
> -		return xe_sriov_vf_migration_disable(xe,
> -				"requires gfx version >= 20, but only %u found",
> -				GRAPHICS_VER(xe));
> +	if (!xe_device_has_memirq(xe))
> +		return xe_sriov_vf_migration_disable(xe, "requires memory-based IRQ support");

but this looks ok, so

Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>

>  
>  	xe->sriov.vf.migration.enabled = true;
>  }


  reply	other threads:[~2025-10-20 21:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 20:58 [PATCH v4 0/4] drm/xe/vf: Minor fixes to post-migration recovery Tomasz Lis
2025-10-20 20:58 ` [PATCH v4 1/4] drm/xe/vf: Helper for telling whether CCS migration BBs are needed Tomasz Lis
2025-10-20 20:58 ` [PATCH v4 2/4] drm/xe/vf: Fix GuC FW check for VF migration support Tomasz Lis
2025-10-20 22:17   ` Michal Wajdeczko
2025-10-20 23:46     ` Lis, Tomasz
2025-10-20 20:58 ` [PATCH v4 3/4] drm/xe: Assert that VF will never use fixed placement of BOs Tomasz Lis
2025-10-20 21:59   ` Michal Wajdeczko
2025-10-20 22:48     ` Lis, Tomasz
2025-10-21 15:04       ` Michal Wajdeczko
2025-10-21 17:20         ` Lis, Tomasz
2025-10-20 20:58 ` [PATCH v4 4/4] drm/xe/vf: Do not disable VF migration on ATS-M Tomasz Lis
2025-10-20 21:53   ` Michal Wajdeczko [this message]
2025-10-21 10:51 ` ✓ CI.KUnit: success for drm/xe/vf: Minor fixes to post-migration recovery (rev4) Patchwork
2025-10-21 12:41 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-21 13:38 ` ✓ Xe.CI.Full: " 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=ddb0a685-e0fd-428c-b292-7925011d89d8@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=michal.winiarski@intel.com \
    --cc=piotr.piorkowski@intel.com \
    --cc=satyanarayana.k.v.p@intel.com \
    --cc=tomasz.lis@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