All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
Date: Thu, 07 Dec 2023 08:39:46 +0000	[thread overview]
Message-ID: <87cyvi8kz1.wl-maz@kernel.org> (raw)
In-Reply-To: <20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>

On Tue, 05 Dec 2023 16:48:13 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> FEAT_FPMR introduces a new system register FPMR which allows configuration
> of floating point behaviour, currently for FP8 specific features. Allow use
> of this in guests, disabling the trap while guests are running and saving
> and restoring the value along with the rest of the floating point state.
> Since FPMR is stored immediately after the main floating point state we
> share it with the hypervisor by adjusting the size of the shared region.
> 
> Access to FPMR is covered by both a register specific trap HCRX_EL2.EnFPM
> and the overall floating point access trap so we just unconditionally
> enable the FPMR specific trap and rely on the floating point access trap to
> detect guest floating point usage.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/kvm_arm.h        |  2 +-
>  arch/arm64/include/asm/kvm_host.h       |  4 +++-
>  arch/arm64/kvm/emulate-nested.c         |  9 +++++++++
>  arch/arm64/kvm/fpsimd.c                 | 20 +++++++++++++++++---
>  arch/arm64/kvm/hyp/include/hyp/switch.h |  7 ++++++-
>  arch/arm64/kvm/sys_regs.c               | 11 +++++++++++
>  6 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 9f9239d86900..95f3b44e7c3a 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -103,7 +103,7 @@
>  #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
>  
>  #define HCRX_GUEST_FLAGS \
> -	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
> +	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM | \

We really should start making all of these things conditional. See
below.

>  	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
>  #define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM)
>  
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index f8d98985a39c..9885adff06fa 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -391,6 +391,8 @@ enum vcpu_sysreg {
>  	CNTP_CVAL_EL0,
>  	CNTP_CTL_EL0,
>  
> +	FPMR,
> +
>  	/* Memory Tagging Extension registers */
>  	RGSR_EL1,	/* Random Allocation Tag Seed Register */
>  	GCR_EL1,	/* Tag Control Register */
> @@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
>  	enum fp_type fp_type;
>  	unsigned int sve_max_vl;
>  	u64 svcr;
> -	u64 fpmr;

Why do this change here? Why isn't done like that the first place?

>  
>  	/* Stage 2 paging state used by the hardware on next switch */
>  	struct kvm_s2_mmu *hw_mmu;
> @@ -576,6 +577,7 @@ struct kvm_vcpu_arch {
>  	struct kvm_guest_debug_arch external_debug_state;
>  
>  	struct user_fpsimd_state *host_fpsimd_state;	/* hyp VA */
> +	u64 *host_fpmr;					/* hyp VA */
>  	struct task_struct *parent_task;
>  
>  	struct {
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 06185216a297..802e5cde696f 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -67,6 +67,8 @@ enum cgt_group_id {
>  	CGT_HCR_TTLBIS,
>  	CGT_HCR_TTLBOS,
>  
> +	CGT_HCRX_EnFPM,
> +
>  	CGT_MDCR_TPMCR,
>  	CGT_MDCR_TPM,
>  	CGT_MDCR_TDE,
> @@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
>  		.mask		= HCR_TTLBOS,
>  		.behaviour	= BEHAVE_FORWARD_ANY,
>  	},
> +	[CGT_HCRX_EnFPM] = {
> +		.index		= HCRX_EL2,
> +		.value		= HCRX_EL2_EnFPM,
> +		.mask		= HCRX_EL2_EnFPM,
> +		.behaviour	= BEHAVE_FORWARD_ANY,

This looks wrong. HCRX_EL2.EnFPM is an enable bit.

> +	},
>  	[CGT_MDCR_TPMCR] = {
>  		.index		= MDCR_EL2,
>  		.value		= MDCR_EL2_TPMCR,
> @@ -478,6 +486,7 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = {
>  	SR_TRAP(SYS_AIDR_EL1,		CGT_HCR_TID1),
>  	SR_TRAP(SYS_SMIDR_EL1,		CGT_HCR_TID1),
>  	SR_TRAP(SYS_CTR_EL0,		CGT_HCR_TID2),
> +	SR_TRAP(SYS_FPMR,		CGT_HCRX_EnFPM),
>  	SR_TRAP(SYS_CCSIDR_EL1,		CGT_HCR_TID2_TID4),
>  	SR_TRAP(SYS_CCSIDR2_EL1,	CGT_HCR_TID2_TID4),
>  	SR_TRAP(SYS_CLIDR_EL1,		CGT_HCR_TID2_TID4),
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index e3e611e30e91..dee078625d0d 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -14,6 +14,16 @@
>  #include <asm/kvm_mmu.h>
>  #include <asm/sysreg.h>
>  
> +static void *fpsimd_share_end(struct user_fpsimd_state *fpsimd)
> +{
> +	void *share_end = fpsimd + 1;
> +
> +	if (cpus_have_final_cap(ARM64_HAS_FPMR))
> +		share_end += sizeof(u64);
> +
> +	return share_end;
> +}

This is horrible. Why can't you just have a new structure wrapping
both user_fpsimd_state and fpmr? This is going to break in subtle
ways, just like the SVE/SME stuff.

> +
>  void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
>  {
>  	struct task_struct *p = vcpu->arch.parent_task;
> @@ -23,7 +33,7 @@ void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
>  		return;
>  
>  	fpsimd = &p->thread.uw.fpsimd_state;
> -	kvm_unshare_hyp(fpsimd, fpsimd + 1);
> +	kvm_unshare_hyp(fpsimd, fpsimd_share_end(fpsimd));
>  	put_task_struct(p);
>  }
>  
> @@ -45,11 +55,15 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  	kvm_vcpu_unshare_task_fp(vcpu);
>  
>  	/* Make sure the host task fpsimd state is visible to hyp: */
> -	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
> +	ret = kvm_share_hyp(fpsimd, fpsimd_share_end(fpsimd));
>  	if (ret)
>  		return ret;
>  
>  	vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
> +	if (cpus_have_final_cap(ARM64_HAS_FPMR)) {
> +		WARN_ON_ONCE(&current->thread.fpmr + 1 != fpsimd_share_end(fpsimd));

How can this happen?

> +		vcpu->arch.host_fpmr = kern_hyp_va(&current->thread.fpmr);
> +	}

We really need to stop piling the save/restore of stuff that isn't
advertised to the guest.

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Jonathan Corbet <corbet@lwn.net>, Shuah Khan <shuah@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests
Date: Thu, 07 Dec 2023 08:39:46 +0000	[thread overview]
Message-ID: <87cyvi8kz1.wl-maz@kernel.org> (raw)
In-Reply-To: <20231205-arm64-2023-dpisa-v3-15-dbcbcd867a7f@kernel.org>

On Tue, 05 Dec 2023 16:48:13 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> FEAT_FPMR introduces a new system register FPMR which allows configuration
> of floating point behaviour, currently for FP8 specific features. Allow use
> of this in guests, disabling the trap while guests are running and saving
> and restoring the value along with the rest of the floating point state.
> Since FPMR is stored immediately after the main floating point state we
> share it with the hypervisor by adjusting the size of the shared region.
> 
> Access to FPMR is covered by both a register specific trap HCRX_EL2.EnFPM
> and the overall floating point access trap so we just unconditionally
> enable the FPMR specific trap and rely on the floating point access trap to
> detect guest floating point usage.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/kvm_arm.h        |  2 +-
>  arch/arm64/include/asm/kvm_host.h       |  4 +++-
>  arch/arm64/kvm/emulate-nested.c         |  9 +++++++++
>  arch/arm64/kvm/fpsimd.c                 | 20 +++++++++++++++++---
>  arch/arm64/kvm/hyp/include/hyp/switch.h |  7 ++++++-
>  arch/arm64/kvm/sys_regs.c               | 11 +++++++++++
>  6 files changed, 47 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 9f9239d86900..95f3b44e7c3a 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -103,7 +103,7 @@
>  #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
>  
>  #define HCRX_GUEST_FLAGS \
> -	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | \
> +	(HCRX_EL2_SMPME | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM | \

We really should start making all of these things conditional. See
below.

>  	 (cpus_have_final_cap(ARM64_HAS_MOPS) ? (HCRX_EL2_MSCEn | HCRX_EL2_MCE2) : 0))
>  #define HCRX_HOST_FLAGS (HCRX_EL2_MSCEn | HCRX_EL2_TCR2En | HCRX_EL2_EnFPM)
>  
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index f8d98985a39c..9885adff06fa 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -391,6 +391,8 @@ enum vcpu_sysreg {
>  	CNTP_CVAL_EL0,
>  	CNTP_CTL_EL0,
>  
> +	FPMR,
> +
>  	/* Memory Tagging Extension registers */
>  	RGSR_EL1,	/* Random Allocation Tag Seed Register */
>  	GCR_EL1,	/* Tag Control Register */
> @@ -517,7 +519,6 @@ struct kvm_vcpu_arch {
>  	enum fp_type fp_type;
>  	unsigned int sve_max_vl;
>  	u64 svcr;
> -	u64 fpmr;

Why do this change here? Why isn't done like that the first place?

>  
>  	/* Stage 2 paging state used by the hardware on next switch */
>  	struct kvm_s2_mmu *hw_mmu;
> @@ -576,6 +577,7 @@ struct kvm_vcpu_arch {
>  	struct kvm_guest_debug_arch external_debug_state;
>  
>  	struct user_fpsimd_state *host_fpsimd_state;	/* hyp VA */
> +	u64 *host_fpmr;					/* hyp VA */
>  	struct task_struct *parent_task;
>  
>  	struct {
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 06185216a297..802e5cde696f 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -67,6 +67,8 @@ enum cgt_group_id {
>  	CGT_HCR_TTLBIS,
>  	CGT_HCR_TTLBOS,
>  
> +	CGT_HCRX_EnFPM,
> +
>  	CGT_MDCR_TPMCR,
>  	CGT_MDCR_TPM,
>  	CGT_MDCR_TDE,
> @@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
>  		.mask		= HCR_TTLBOS,
>  		.behaviour	= BEHAVE_FORWARD_ANY,
>  	},
> +	[CGT_HCRX_EnFPM] = {
> +		.index		= HCRX_EL2,
> +		.value		= HCRX_EL2_EnFPM,
> +		.mask		= HCRX_EL2_EnFPM,
> +		.behaviour	= BEHAVE_FORWARD_ANY,

This looks wrong. HCRX_EL2.EnFPM is an enable bit.

> +	},
>  	[CGT_MDCR_TPMCR] = {
>  		.index		= MDCR_EL2,
>  		.value		= MDCR_EL2_TPMCR,
> @@ -478,6 +486,7 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = {
>  	SR_TRAP(SYS_AIDR_EL1,		CGT_HCR_TID1),
>  	SR_TRAP(SYS_SMIDR_EL1,		CGT_HCR_TID1),
>  	SR_TRAP(SYS_CTR_EL0,		CGT_HCR_TID2),
> +	SR_TRAP(SYS_FPMR,		CGT_HCRX_EnFPM),
>  	SR_TRAP(SYS_CCSIDR_EL1,		CGT_HCR_TID2_TID4),
>  	SR_TRAP(SYS_CCSIDR2_EL1,	CGT_HCR_TID2_TID4),
>  	SR_TRAP(SYS_CLIDR_EL1,		CGT_HCR_TID2_TID4),
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index e3e611e30e91..dee078625d0d 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -14,6 +14,16 @@
>  #include <asm/kvm_mmu.h>
>  #include <asm/sysreg.h>
>  
> +static void *fpsimd_share_end(struct user_fpsimd_state *fpsimd)
> +{
> +	void *share_end = fpsimd + 1;
> +
> +	if (cpus_have_final_cap(ARM64_HAS_FPMR))
> +		share_end += sizeof(u64);
> +
> +	return share_end;
> +}

This is horrible. Why can't you just have a new structure wrapping
both user_fpsimd_state and fpmr? This is going to break in subtle
ways, just like the SVE/SME stuff.

> +
>  void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
>  {
>  	struct task_struct *p = vcpu->arch.parent_task;
> @@ -23,7 +33,7 @@ void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
>  		return;
>  
>  	fpsimd = &p->thread.uw.fpsimd_state;
> -	kvm_unshare_hyp(fpsimd, fpsimd + 1);
> +	kvm_unshare_hyp(fpsimd, fpsimd_share_end(fpsimd));
>  	put_task_struct(p);
>  }
>  
> @@ -45,11 +55,15 @@ int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
>  	kvm_vcpu_unshare_task_fp(vcpu);
>  
>  	/* Make sure the host task fpsimd state is visible to hyp: */
> -	ret = kvm_share_hyp(fpsimd, fpsimd + 1);
> +	ret = kvm_share_hyp(fpsimd, fpsimd_share_end(fpsimd));
>  	if (ret)
>  		return ret;
>  
>  	vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
> +	if (cpus_have_final_cap(ARM64_HAS_FPMR)) {
> +		WARN_ON_ONCE(&current->thread.fpmr + 1 != fpsimd_share_end(fpsimd));

How can this happen?

> +		vcpu->arch.host_fpmr = kern_hyp_va(&current->thread.fpmr);
> +	}

We really need to stop piling the save/restore of stuff that isn't
advertised to the guest.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-12-07  8:40 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 16:47 [PATCH v3 00/21] arm64: Support for 2023 DPISA extensions Mark Brown
2023-12-05 16:47 ` Mark Brown
2023-12-05 16:47 ` [PATCH v3 01/21] arm64/sysreg: Add definition for ID_AA64PFR2_EL1 Mark Brown
2023-12-05 16:47   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 02/21] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for DDI0601 2023-09 Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 03/21] arm64/sysreg: Add definition for ID_AA64ISAR3_EL1 Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 04/21] arm64/sysreg: Add definition for ID_AA64FPFR0_EL1 Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 05/21] arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for DDI0601 2023-09 Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 06/21] arm64/sysreg: Update SCTLR_EL1 " Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 07/21] arm64/sysreg: Update HCRX_EL2 definition " Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 08/21] arm64/sysreg: Add definition for FPMR Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 09/21] arm64/cpufeature: Hook new identification registers up to cpufeature Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 10/21] arm64/fpsimd: Enable host kernel access to FPMR Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 11/21] arm64/fpsimd: Support FEAT_FPMR Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 12/21] arm64/signal: Add FPMR signal handling Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 13/21] arm64/ptrace: Expose FPMR via ptrace Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 14/21] KVM: arm64: Add newly allocated ID registers to register descriptions Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 15/21] KVM: arm64: Support FEAT_FPMR for guests Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-07  8:39   ` Marc Zyngier [this message]
2023-12-07  8:39     ` Marc Zyngier
2023-12-07 12:30     ` Mark Brown
2023-12-07 12:30       ` Mark Brown
2023-12-07 14:06       ` Marc Zyngier
2023-12-07 14:06         ` Marc Zyngier
2023-12-07 15:47         ` Mark Brown
2023-12-07 15:47           ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 16/21] arm64/hwcap: Define hwcaps for 2023 DPISA features Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 17/21] kselftest/arm64: Handle FPMR context in generic signal frame parser Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 18/21] kselftest/arm64: Add basic FPMR test Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 19/21] kselftest/arm64: Add 2023 DPISA hwcap test coverage Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 20/21] KVM: arm64: selftests: Document feature registers added in 2023 extensions Mark Brown
2023-12-05 16:48   ` Mark Brown
2023-12-05 16:48 ` [PATCH v3 21/21] KVM: arm64: selftests: Teach get-reg-list about FPMR Mark Brown
2023-12-05 16:48   ` Mark Brown

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=87cyvi8kz1.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=shuah@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.