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

[Oliver Upton <oliver.upton@linux.dev>]

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