[PATCH v2 0/5] KVM: arm64: FEAT_RASv1p1 support and RAS selection

[PATCH v2 0/5] KVM: arm64: FEAT_RASv1p1 support and RAS selection

[Marc Zyngier]

This is the next iteration of this series trying to plug some of our
RAS holes (no pun intended...). See [1] for the original series.

Patches on top of kvmarm-6.17.

* From v1 [1]:

  - Bunch of patches picked by Oliver (thanks!)

  - Added missing SYS_ERXMISC{2,3}_EL1 from the list of handled RAS
    registers

 - Added some rationale about the advertising of RASv1p1 (Cornelia)

  - Picked AB from Catalin (thanks!)

[1] https://lore.kernel.org/kvmarm/20250721101955.535159-1-maz@kernel.org

Marc Zyngier (5):
  arm64: Add capability denoting FEAT_RASv1p1
  KVM: arm64: Handle RASv1p1 registers
  KVM: arm64: Ignore HCR_EL2.FIEN set by L1 guest's EL2
  KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner
  KVM: arm64: Make ID_AA64PFR0_EL1.RAS writable

 arch/arm64/kernel/cpufeature.c  | 24 ++++++++++++++++++++++++
 arch/arm64/kvm/hyp/vhe/switch.c |  5 ++++-
 arch/arm64/kvm/sys_regs.c       | 30 +++++++++++++++++++++++++++++-
 arch/arm64/tools/cpucaps        |  1 +
 4 files changed, 58 insertions(+), 2 deletions(-)

-- 
2.39.2

[PATCH v2 1/5] arm64: Add capability denoting FEAT_RASv1p1

[Marc Zyngier]

Detecting FEAT_RASv1p1 is rather complicated, as there are two
ways for the architecture to advertise the same thing (always a
delight...).

Add a capability that will advertise this in a synthetic way to
the rest of the kernel.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 24 ++++++++++++++++++++++++
 arch/arm64/tools/cpucaps       |  1 +
 2 files changed, 25 insertions(+)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 4dece9ca68bc6..22a94e548362d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2235,6 +2235,24 @@ static void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused)
 	/* Firmware may have left a deferred SError in this register. */
 	write_sysreg_s(0, SYS_DISR_EL1);
 }
+static bool has_rasv1p1(const struct arm64_cpu_capabilities *__unused, int scope)
+{
+	const struct arm64_cpu_capabilities rasv1p1_caps[] = {
+		{
+			ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, RAS, V1P1)
+		},
+		{
+			ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, RAS, IMP)
+		},
+		{
+			ARM64_CPUID_FIELDS(ID_AA64PFR1_EL1, RAS_frac, RASv1p1)
+		},
+	};
+
+	return (has_cpuid_feature(&rasv1p1_caps[0], scope) ||
+		(has_cpuid_feature(&rasv1p1_caps[1], scope) &&
+		 has_cpuid_feature(&rasv1p1_caps[2], scope)));
+}
 #endif /* CONFIG_ARM64_RAS_EXTN */
 
 #ifdef CONFIG_ARM64_PTR_AUTH
@@ -2653,6 +2671,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.cpu_enable = cpu_clear_disr,
 		ARM64_CPUID_FIELDS(ID_AA64PFR0_EL1, RAS, IMP)
 	},
+	{
+		.desc = "RASv1p1 Extension Support",
+		.capability = ARM64_HAS_RASV1P1_EXTN,
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.matches = has_rasv1p1,
+	},
 #endif /* CONFIG_ARM64_RAS_EXTN */
 #ifdef CONFIG_ARM64_AMU_EXTN
 	{
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 115161dd9a24d..eb7f1f5622a8f 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -52,6 +52,7 @@ HAS_S1PIE
 HAS_S1POE
 HAS_SCTLR2
 HAS_RAS_EXTN
+HAS_RASV1P1_EXTN
 HAS_RNG
 HAS_SB
 HAS_STAGE2_FWB
-- 
2.39.2

[PATCH v2 2/5] KVM: arm64: Handle RASv1p1 registers

[Marc Zyngier]

FEAT_RASv1p1 system registeres are not handled at all so far.
KVM will give an embarassed warning on the console and inject
an UNDEF, despite RASv1p1 being exposed to the guest on suitable HW.

Handle these registers similarly to FEAT_RAS, with the added fun
that there are *two* way to indicate the presence of FEAT_RASv1p1.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ad25484772574..1b4114790024e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2695,6 +2695,18 @@ static bool access_ras(struct kvm_vcpu *vcpu,
 	struct kvm *kvm = vcpu->kvm;
 
 	switch(reg_to_encoding(r)) {
+	case SYS_ERXPFGCDN_EL1:
+	case SYS_ERXPFGCTL_EL1:
+	case SYS_ERXPFGF_EL1:
+	case SYS_ERXMISC2_EL1:
+	case SYS_ERXMISC3_EL1:
+		if (!(kvm_has_feat(kvm, ID_AA64PFR0_EL1, RAS, V1P1) ||
+		      (kvm_has_feat_enum(kvm, ID_AA64PFR0_EL1, RAS, IMP) &&
+		       kvm_has_feat(kvm, ID_AA64PFR1_EL1, RAS_frac, RASv1p1)))) {
+			kvm_inject_undefined(vcpu);
+			return false;
+		}
+		break;
 	default:
 		if (!kvm_has_feat(kvm, ID_AA64PFR0_EL1, RAS, IMP)) {
 			kvm_inject_undefined(vcpu);
@@ -3058,8 +3070,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_ERXCTLR_EL1), access_ras },
 	{ SYS_DESC(SYS_ERXSTATUS_EL1), access_ras },
 	{ SYS_DESC(SYS_ERXADDR_EL1), access_ras },
+	{ SYS_DESC(SYS_ERXPFGF_EL1), access_ras },
+	{ SYS_DESC(SYS_ERXPFGCTL_EL1), access_ras },
+	{ SYS_DESC(SYS_ERXPFGCDN_EL1), access_ras },
 	{ SYS_DESC(SYS_ERXMISC0_EL1), access_ras },
 	{ SYS_DESC(SYS_ERXMISC1_EL1), access_ras },
+	{ SYS_DESC(SYS_ERXMISC2_EL1), access_ras },
+	{ SYS_DESC(SYS_ERXMISC3_EL1), access_ras },
 
 	MTE_REG(TFSR_EL1),
 	MTE_REG(TFSRE0_EL1),
-- 
2.39.2

[PATCH v2 3/5] KVM: arm64: Ignore HCR_EL2.FIEN set by L1 guest's EL2

[Marc Zyngier]

An EL2 guest can set HCR_EL2.FIEN, which gives access to the RASv1p1
fault injection mechanism. This would allow an EL1 guest to inject
error records into the system, which does sound like a terrible idea.

Prevent this situation by added FIEN to the list of bits we silently
exclude from being inserted into the host configuration.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/hyp/vhe/switch.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index e482181c66322..0998ad4a25524 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -43,8 +43,11 @@ DEFINE_PER_CPU(unsigned long, kvm_hyp_vector);
  *
  * - API/APK: they are already accounted for by vcpu_load(), and can
  *   only take effect across a load/put cycle (such as ERET)
+ *
+ * - FIEN: no way we let a guest have access to the RAS "Common Fault
+ *   Injection" thing, whatever that does
  */
-#define NV_HCR_GUEST_EXCLUDE	(HCR_TGE | HCR_API | HCR_APK)
+#define NV_HCR_GUEST_EXCLUDE	(HCR_TGE | HCR_API | HCR_APK | HCR_FIEN)
 
 static u64 __compute_hcr(struct kvm_vcpu *vcpu)
 {
-- 
2.39.2

[PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Marc Zyngier]

If we have RASv1p1 on the host, advertise it to the guest in the
"canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
the convoluted RAS+RAS_frac method.

Note that this also advertises FEAT_DoubleFault, which doesn't
affect the guest at all, as only EL3 is concerned by this.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 1b4114790024e..66e5a733e9628 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
 	if (!vcpu_has_sve(vcpu))
 		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
 
+	/*
+	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
+	 * is cleared separately. Note that by advertising RASv1p1 here, we
+	 * implicitly advertise FEAT_DoubleFault. However, since that last
+	 * feature is a pure EL3 feature, this is not relevant for the
+	 * guest, and we save on the complexity.
+	 */
+	if (cpus_have_final_cap(ARM64_HAS_RASV1P1_EXTN)) {
+		val &= ~ID_AA64PFR0_EL1_RAS;
+		val |= SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, RAS, V1P1);
+	}
+
 	/*
 	 * The default is to expose CSV2 == 1 if the HW isn't affected.
 	 * Although this is a per-CPU feature, we make it global because
-- 
2.39.2

[PATCH v2 5/5] KVM: arm64: Make ID_AA64PFR0_EL1.RAS writable

[Marc Zyngier]

Make ID_AA64PFR0_EL1.RAS writable so that we can restore a VM from
a system without RAS to a RAS-equipped machine (or disable RAS
in the guest).

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/sys_regs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 66e5a733e9628..3a50ade091491 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2951,7 +2951,6 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 		    ~(ID_AA64PFR0_EL1_AMU |
 		      ID_AA64PFR0_EL1_MPAM |
 		      ID_AA64PFR0_EL1_SVE |
-		      ID_AA64PFR0_EL1_RAS |
 		      ID_AA64PFR0_EL1_AdvSIMD |
 		      ID_AA64PFR0_EL1_FP)),
 	ID_FILTERED(ID_AA64PFR1_EL1, id_aa64pfr1_el1,
-- 
2.39.2

Re: [PATCH v2 2/5] KVM: arm64: Handle RASv1p1 registers

[Joey Gouly]

Hi!

On Wed, Aug 06, 2025 at 05:56:12PM +0100, Marc Zyngier wrote:
> FEAT_RASv1p1 system registeres are not handled at all so far.
*registers
> KVM will give an embarassed warning on the console and inject
*embarrassed
> an UNDEF, despite RASv1p1 being exposed to the guest on suitable HW.
> 
> Handle these registers similarly to FEAT_RAS, with the added fun
> that there are *two* way to indicate the presence of FEAT_RASv1p1.
> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>

Reviewed-by: Joey Gouly <joey.gouly@arm.com>

> ---
>  arch/arm64/kvm/sys_regs.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index ad25484772574..1b4114790024e 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2695,6 +2695,18 @@ static bool access_ras(struct kvm_vcpu *vcpu,
>  	struct kvm *kvm = vcpu->kvm;
>  
>  	switch(reg_to_encoding(r)) {
> +	case SYS_ERXPFGCDN_EL1:
> +	case SYS_ERXPFGCTL_EL1:
> +	case SYS_ERXPFGF_EL1:
> +	case SYS_ERXMISC2_EL1:
> +	case SYS_ERXMISC3_EL1:
> +		if (!(kvm_has_feat(kvm, ID_AA64PFR0_EL1, RAS, V1P1) ||
> +		      (kvm_has_feat_enum(kvm, ID_AA64PFR0_EL1, RAS, IMP) &&
> +		       kvm_has_feat(kvm, ID_AA64PFR1_EL1, RAS_frac, RASv1p1)))) {
> +			kvm_inject_undefined(vcpu);
> +			return false;
> +		}
> +		break;
>  	default:
>  		if (!kvm_has_feat(kvm, ID_AA64PFR0_EL1, RAS, IMP)) {
>  			kvm_inject_undefined(vcpu);
> @@ -3058,8 +3070,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  	{ SYS_DESC(SYS_ERXCTLR_EL1), access_ras },
>  	{ SYS_DESC(SYS_ERXSTATUS_EL1), access_ras },
>  	{ SYS_DESC(SYS_ERXADDR_EL1), access_ras },
> +	{ SYS_DESC(SYS_ERXPFGF_EL1), access_ras },
> +	{ SYS_DESC(SYS_ERXPFGCTL_EL1), access_ras },
> +	{ SYS_DESC(SYS_ERXPFGCDN_EL1), access_ras },
>  	{ SYS_DESC(SYS_ERXMISC0_EL1), access_ras },
>  	{ SYS_DESC(SYS_ERXMISC1_EL1), access_ras },
> +	{ SYS_DESC(SYS_ERXMISC2_EL1), access_ras },
> +	{ SYS_DESC(SYS_ERXMISC3_EL1), access_ras },
>  
>  	MTE_REG(TFSR_EL1),
>  	MTE_REG(TFSRE0_EL1),
> -- 
> 2.39.2
> 

Re: [PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Joey Gouly]

On Wed, Aug 06, 2025 at 05:56:14PM +0100, Marc Zyngier wrote:
> If we have RASv1p1 on the host, advertise it to the guest in the
> "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
> the convoluted RAS+RAS_frac method.
> 
> Note that this also advertises FEAT_DoubleFault, which doesn't
> affect the guest at all, as only EL3 is concerned by this.
> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 1b4114790024e..66e5a733e9628 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
>  	if (!vcpu_has_sve(vcpu))
>  		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
>  
> +	/*
> +	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
> +	 * is cleared separately. Note that by advertising RASv1p1 here, we

Where is it cleared? __kvm_read_sanitised_id_reg() is where I would have
expected to see it:

    case SYS_ID_AA64PFR1_EL1:                                                                                                                                                                  
        if (!kvm_has_mte(vcpu->kvm)) {                                                                                                                                                         
            val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);                                                                                                                                   
            val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE_frac);                                                                                                                              
        }                                                                                                                                                                                      
                                                                                                                                                                                               
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SME);                                                                                                                                       
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_RNDR_trap);                                                                                                                                 
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_NMI);                                                                                                                                       
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_GCS);                                                                                                                                       
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_THE);                                                                                                                                       
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTEX);                                                                                                                                      
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_PFAR);                                                                                                                                      
        val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MPAM_frac);                                                                                                                                 
        break;                                                                  

> +	 * implicitly advertise FEAT_DoubleFault. However, since that last
> +	 * feature is a pure EL3 feature, this is not relevant for the
> +	 * guest, and we save on the complexity.
> +	 */
> +	if (cpus_have_final_cap(ARM64_HAS_RASV1P1_EXTN)) {
> +		val &= ~ID_AA64PFR0_EL1_RAS;
> +		val |= SYS_FIELD_PREP_ENUM(ID_AA64PFR0_EL1, RAS, V1P1);
> +	}
> +
>  	/*
>  	 * The default is to expose CSV2 == 1 if the HW isn't affected.
>  	 * Although this is a per-CPU feature, we make it global because
> -- 
> 2.39.2
> 

Re: [PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Oliver Upton]

On Thu, Aug 07, 2025 at 01:55:31PM +0100, Joey Gouly wrote:
> On Wed, Aug 06, 2025 at 05:56:14PM +0100, Marc Zyngier wrote:
> > If we have RASv1p1 on the host, advertise it to the guest in the
> > "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
> > the convoluted RAS+RAS_frac method.
> > 
> > Note that this also advertises FEAT_DoubleFault, which doesn't
> > affect the guest at all, as only EL3 is concerned by this.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 1b4114790024e..66e5a733e9628 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
> >  	if (!vcpu_has_sve(vcpu))
> >  		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
> >  
> > +	/*
> > +	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
> > +	 * is cleared separately. Note that by advertising RASv1p1 here, we
> 
> Where is it cleared? __kvm_read_sanitised_id_reg() is where I would have
> expected to see it:

Actually, I'm a bit worried this change doesn't give us very much value
since Marc already does the exhaustive RASv1p1 check in the sysreg
emulation.

There's potential for breakage when migrating VMs between new/old kernels
on systems w/ FEAT_RASv1p1 && !FEAT_DoubleFault.

Marc, WDYT about dropping this patch and instead opening up RAS_frac to
writes?

Thanks,
Oliver

Re: [PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Marc Zyngier]

On Thu, 07 Aug 2025 13:55:31 +0100,
Joey Gouly <joey.gouly@arm.com> wrote:
> 
> On Wed, Aug 06, 2025 at 05:56:14PM +0100, Marc Zyngier wrote:
> > If we have RASv1p1 on the host, advertise it to the guest in the
> > "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
> > the convoluted RAS+RAS_frac method.
> > 
> > Note that this also advertises FEAT_DoubleFault, which doesn't
> > affect the guest at all, as only EL3 is concerned by this.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 1b4114790024e..66e5a733e9628 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
> >  	if (!vcpu_has_sve(vcpu))
> >  		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
> >  
> > +	/*
> > +	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
> > +	 * is cleared separately. Note that by advertising RASv1p1 here, we
> 
> Where is it cleared? __kvm_read_sanitised_id_reg() is where I would have
> expected to see it:
> 
>     case SYS_ID_AA64PFR1_EL1:

[...]

Ah crap, it is the nested code that we get rid of it, nowhere else.
Which means that non-nested VMs have already observed RAS_frac. What a
mess. Then RAS_frac must be exposed as writable.

The question is whether we want to allow migration between one flavour
of RASv1p1 and the other.

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Marc Zyngier]

On Fri, 08 Aug 2025 23:48:32 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Thu, Aug 07, 2025 at 01:55:31PM +0100, Joey Gouly wrote:
> > On Wed, Aug 06, 2025 at 05:56:14PM +0100, Marc Zyngier wrote:
> > > If we have RASv1p1 on the host, advertise it to the guest in the
> > > "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
> > > the convoluted RAS+RAS_frac method.
> > > 
> > > Note that this also advertises FEAT_DoubleFault, which doesn't
> > > affect the guest at all, as only EL3 is concerned by this.
> > > 
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > ---
> > >  arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > > index 1b4114790024e..66e5a733e9628 100644
> > > --- a/arch/arm64/kvm/sys_regs.c
> > > +++ b/arch/arm64/kvm/sys_regs.c
> > > @@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
> > >  	if (!vcpu_has_sve(vcpu))
> > >  		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
> > >  
> > > +	/*
> > > +	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
> > > +	 * is cleared separately. Note that by advertising RASv1p1 here, we
> > 
> > Where is it cleared? __kvm_read_sanitised_id_reg() is where I would have
> > expected to see it:
> 
> Actually, I'm a bit worried this change doesn't give us very much value
> since Marc already does the exhaustive RASv1p1 check in the sysreg
> emulation.
> 
> There's potential for breakage when migrating VMs between new/old kernels
> on systems w/ FEAT_RASv1p1 && !FEAT_DoubleFault.
> 
> Marc, WDYT about dropping this patch and instead opening up RAS_frac to
> writes?

That's indeed probably best. But the question I can't manage to answer
right now is how we migrate RASv1p1 between the two versions? It means
cross-idreg dependencies, ordering and all that, and I'm a bit
reluctant to do so.

Thoughts?

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Cornelia Huck]

On Sat, Aug 09 2025, Marc Zyngier <maz@kernel.org> wrote:

> On Thu, 07 Aug 2025 13:55:31 +0100,
> Joey Gouly <joey.gouly@arm.com> wrote:
>> 
>> On Wed, Aug 06, 2025 at 05:56:14PM +0100, Marc Zyngier wrote:
>> > If we have RASv1p1 on the host, advertise it to the guest in the
>> > "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
>> > the convoluted RAS+RAS_frac method.
>> > 
>> > Note that this also advertises FEAT_DoubleFault, which doesn't
>> > affect the guest at all, as only EL3 is concerned by this.
>> > 
>> > Signed-off-by: Marc Zyngier <maz@kernel.org>
>> > ---
>> >  arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
>> >  1 file changed, 12 insertions(+)
>> > 
>> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> > index 1b4114790024e..66e5a733e9628 100644
>> > --- a/arch/arm64/kvm/sys_regs.c
>> > +++ b/arch/arm64/kvm/sys_regs.c
>> > @@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
>> >  	if (!vcpu_has_sve(vcpu))
>> >  		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
>> >  
>> > +	/*
>> > +	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
>> > +	 * is cleared separately. Note that by advertising RASv1p1 here, we
>> 
>> Where is it cleared? __kvm_read_sanitised_id_reg() is where I would have
>> expected to see it:
>> 
>>     case SYS_ID_AA64PFR1_EL1:
>
> [...]
>
> Ah crap, it is the nested code that we get rid of it, nowhere else.
> Which means that non-nested VMs have already observed RAS_frac. What a
> mess. Then RAS_frac must be exposed as writable.
>
> The question is whether we want to allow migration between one flavour
> of RASv1p1 and the other.

I guess that boils down to which kind of observable changes we want to
allow: bit-for-bit register contents, or only features? If only feature
stability is needed, then a cross-flavour migration would be fine; OTOH,
we do not know how a guest deduces feature availability, and it might
check for one flavour, but not the other (which is mostly a problem if
it re-checks during the lifetime.)

Only looking at strictly matching register contents would probably be
easier to implement for the VMM (well, it looks easier for QEMU :)

Re: [PATCH v2 4/5] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Oliver Upton]

On Sat, Aug 09, 2025 at 09:21:39PM +0100, Marc Zyngier wrote:
> On Fri, 08 Aug 2025 23:48:32 +0100,
> Oliver Upton <oliver.upton@linux.dev> wrote:
> > 
> > On Thu, Aug 07, 2025 at 01:55:31PM +0100, Joey Gouly wrote:
> > > On Wed, Aug 06, 2025 at 05:56:14PM +0100, Marc Zyngier wrote:
> > > > If we have RASv1p1 on the host, advertise it to the guest in the
> > > > "canonical way", by setting ID_AA64PFR0_EL1 to V1P1, rather than
> > > > the convoluted RAS+RAS_frac method.
> > > > 
> > > > Note that this also advertises FEAT_DoubleFault, which doesn't
> > > > affect the guest at all, as only EL3 is concerned by this.
> > > > 
> > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > ---
> > > >  arch/arm64/kvm/sys_regs.c | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > > > index 1b4114790024e..66e5a733e9628 100644
> > > > --- a/arch/arm64/kvm/sys_regs.c
> > > > +++ b/arch/arm64/kvm/sys_regs.c
> > > > @@ -1800,6 +1800,18 @@ static u64 sanitise_id_aa64pfr0_el1(const struct kvm_vcpu *vcpu, u64 val)
> > > >  	if (!vcpu_has_sve(vcpu))
> > > >  		val &= ~ID_AA64PFR0_EL1_SVE_MASK;
> > > >  
> > > > +	/*
> > > > +	 * Describe RASv1p1 in a canonical way -- ID_AA64PFR1_EL1.RAS_frac
> > > > +	 * is cleared separately. Note that by advertising RASv1p1 here, we
> > > 
> > > Where is it cleared? __kvm_read_sanitised_id_reg() is where I would have
> > > expected to see it:
> > 
> > Actually, I'm a bit worried this change doesn't give us very much value
> > since Marc already does the exhaustive RASv1p1 check in the sysreg
> > emulation.
> > 
> > There's potential for breakage when migrating VMs between new/old kernels
> > on systems w/ FEAT_RASv1p1 && !FEAT_DoubleFault.
> > 
> > Marc, WDYT about dropping this patch and instead opening up RAS_frac to
> > writes?
> 
> That's indeed probably best. But the question I can't manage to answer
> right now is how we migrate RASv1p1 between the two versions? It means
> cross-idreg dependencies, ordering and all that, and I'm a bit
> reluctant to do so.

Adding our offline conversation to the list in case folks have any
concerns.

Next steps here are to allow the RAS_frac mechanism for RASv1p1 only on
RASv1p1 machines (to protect against turds like a potential RASv2p1) and
allow the user to de-feature the RAS_frac field.

A VMM that wants to migrate cross-implementation (with mixed support for
FEAT_DoubleFault) will need to compute the intersection of CPU features
and decide it needs to de-feature FEAT_RASv1p1 anyway (RAS = 0x1,
RAS_frac = 0x0) so the canonicalization isn't that big of a deal.

Thanks,
Oliver