Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Michal Wajdeczko <michal.wajdeczko@intel.com>,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH v2] drm/xe/migrate: Atomicize CCS copy command setup
Date: Fri, 26 Sep 2025 12:51:57 -0700	[thread overview]
Message-ID: <aNbu3ROORoQg3NRh@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20250926131437.2228555-1-satyanarayana.k.v.p@intel.com>

On Fri, Sep 26, 2025 at 01:14:37PM +0000, Satyanarayana K V P wrote:
> The CCS copy command is a 5-dword sequence. If the vCPU halts during
> save/restore while this sequence is being programmed, partial writes may
> trigger page faults when saving IGPU CCS metadata. Use the VMOVDQU
> instruction to write the sequence atomically.
> 
> Since VMOVDQU operates on 128-bit chunks, update EMIT_COPY_CCS_DW to emit
> 8 dwords instead of 5 dwords.
> 
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> 
> ---
> V1 -> V2:
> - Use _memcpy_vmovdqu only for x86 arch and for VF. Else use memcpy
>   (Auld, Matthew)
> - Fix issues reported by patchworks.
> ---
>  drivers/gpu/drm/xe/xe_migrate.c | 51 +++++++++++++++++++++++++++------
>  1 file changed, 42 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
> index e2fff2107f68..88ed4d09a97e 100644
> --- a/drivers/gpu/drm/xe/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/xe_migrate.c
> @@ -5,6 +5,7 @@
>  
>  #include "xe_migrate.h"
>  
> +#include <asm/fpu/api.h>
>  #include <linux/bitfield.h>
>  #include <linux/sizes.h>
>  
> @@ -644,18 +645,39 @@ static void emit_pte(struct xe_migrate *m,
>  	}
>  }
>  
> -#define EMIT_COPY_CCS_DW 5
> +#ifdef CONFIG_X86
> +/*
> + * The CCS copy command is a 5-dword sequence. If the vCPU halts during
> + * save/restore while this sequence is being issued, partial writes may trigger
> + * page faults when saving iGPU CCS metadata. Use the VMOVDQU instruction to
> + * write the sequence atomically.
> + */
> +static void memcpy_vmovdqu(void *dst, const void *src)
> +{
> +	kernel_fpu_begin();
> +
> +	asm("vmovdqu (%0), %%ymm0\n"
> +	    "vmovups %%ymm0,   (%1)\n"
> +	    :: "r" (src), "r" (dst) : "memory");
> +
> +	kernel_fpu_end();
> +}
> +#endif

I'd write this part like:

#ifdef CONFIG_X86
/* The code you have above */
#else
static void memcpy_vmovdqu(void *dst, const void *src)
{
	WARN_ON_ONCE("NOT POSSIBLE");
}
#endif

> +
> +#define EMIT_COPY_CCS_DW 8
>  static void emit_copy_ccs(struct xe_gt *gt, struct xe_bb *bb,
>  			  u64 dst_ofs, bool dst_is_indirect,
>  			  u64 src_ofs, bool src_is_indirect,
>  			  u32 size)
>  {
> +	u32 dw[EMIT_COPY_CCS_DW] = {MI_NOOP};
>  	struct xe_device *xe = gt_to_xe(gt);
>  	u32 *cs = bb->cs + bb->len;
>  	u32 num_ccs_blks;
>  	u32 num_pages;
>  	u32 ccs_copy_size;
>  	u32 mocs;
> +	u32 i = 0;
>  
>  	if (GRAPHICS_VERx100(xe) >= 2000) {
>  		num_pages = DIV_ROUND_UP(size, XE_PAGE_SIZE);
> @@ -673,14 +695,25 @@ static void emit_copy_ccs(struct xe_gt *gt, struct xe_bb *bb,
>  		mocs = FIELD_PREP(XY_CTRL_SURF_MOCS_MASK, gt->mocs.uc_index);
>  	}
>  
> -	*cs++ = XY_CTRL_SURF_COPY_BLT |
> -		(src_is_indirect ? 0x0 : 0x1) << SRC_ACCESS_TYPE_SHIFT |
> -		(dst_is_indirect ? 0x0 : 0x1) << DST_ACCESS_TYPE_SHIFT |
> -		ccs_copy_size;
> -	*cs++ = lower_32_bits(src_ofs);
> -	*cs++ = upper_32_bits(src_ofs) | mocs;
> -	*cs++ = lower_32_bits(dst_ofs);
> -	*cs++ = upper_32_bits(dst_ofs) | mocs;
> +	dw[i++] = XY_CTRL_SURF_COPY_BLT |
> +		  (src_is_indirect ? 0x0 : 0x1) << SRC_ACCESS_TYPE_SHIFT |
> +		  (dst_is_indirect ? 0x0 : 0x1) << DST_ACCESS_TYPE_SHIFT |
> +		  ccs_copy_size;
> +	dw[i++] = lower_32_bits(src_ofs);
> +	dw[i++] = upper_32_bits(src_ofs) | mocs;
> +	dw[i++] = lower_32_bits(dst_ofs);
> +	dw[i++] = upper_32_bits(dst_ofs) | mocs;
> +
> +#ifdef CONFIG_X86
> +	if (IS_SRIOV_VF(gt_to_xe(gt)) && static_cpu_has(X86_FEATURE_AVX))
> +		memcpy_vmovdqu(cs, dw);
> +	else
> +		memcpy(cs, dw, sizeof(u32) * EMIT_COPY_CCS_DW);
> +#else
> +	memcpy(cs, dw, sizeof(u32) * EMIT_COPY_CCS_DW);
> +#endif

Then here you won't need ifdef CONFIG_X86, rather just this:

	if (IS_SRIOV_VF(gt_to_xe(gt)) && static_cpu_has(X86_FEATURE_AVX))
		memcpy_vmovdqu(cs, dw);
	else
		memcpy(cs, dw, sizeof(u32) * EMIT_COPY_CCS_DW);

I also think emit_flush_invalidate needs to use memcpy_vmovdqu too.

I think it generally fine for the emit_pte() to be interrupted aside
from maybe the first two DW, so maybe convert that part into a simple QW
store too /w WRITE_ONCE + smp_wmb() so the barriers are correct.

Also the free side could be problematic too. We might need to carefully
use memcpy_vmovdqu to stragically reinsert NOPs in way that is safe
(e.g. clobber emit_flush_invalidate, emit_copy_ccs in single
instructions, for emit_pte work backwards clearing out the write value
first and then final clear first DW /w smp_wmb() + WRITE_ONCE.

We might need to block CCS BO allocations during VF post migration
recovery too, I'll think that part through but if needed we can do that
in a follow up.

Matt

> +
> +	cs += EMIT_COPY_CCS_DW;
>  
>  	bb->len = cs - bb->cs;
>  }
> -- 
> 2.43.0
> 

  parent reply	other threads:[~2025-09-26 19:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-26 13:14 [PATCH v2] drm/xe/migrate: Atomicize CCS copy command setup Satyanarayana K V P
2025-09-26 13:50 ` ✓ CI.KUnit: success for drm/xe/migrate: Atomicize CCS copy command setup (rev2) Patchwork
2025-09-26 14:30 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-26 19:49 ` ✗ Xe.CI.Full: failure " Patchwork
2025-09-26 19:51 ` Matthew Brost [this message]
2025-09-26 20:39 ` [PATCH v2] drm/xe/migrate: Atomicize CCS copy command setup Matthew Brost

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=aNbu3ROORoQg3NRh@lstrano-desk.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=satyanarayana.k.v.p@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