[PATCH 6/7] KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner

[Marc Zyngier]

On Mon, 21 Jul 2025 14:12:19 +0100,
Cornelia Huck <cohuck at redhat.com> wrote:
> 
> On Mon, Jul 21 2025, Marc Zyngier <maz at kernel.org> wrote:
> 
> > On Mon, 21 Jul 2025 13:32:08 +0100,
> > Cornelia Huck <cohuck at redhat.com> wrote:
> >> 
> >> On Mon, Jul 21 2025, Marc Zyngier <maz at kernel.org> 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.
> >> 
> >> Don't the two methods have slightly different semantics with RAS == V1P1
> >> possibly implying FEAT_DoubleFault, and RAS+RAS_frac not?
> >
> > Ah, that's an interesting point -- I definitely had glanced over that.
> >
> > But I'm not sure a guest can actually distinguish between these two
> > configurations, given that FEAT_DoubleFault is essentially an EL3
> > feature (as indicated in the RAS == V1P1 section, and further
> > confirmed in R_GRJVN), making it invisible to the guest.
> >
> > FEAT_DoubleFault2 is, on the contrary, totally visible from the guest,
> > and independent of EL3.
> >
> > Does this make sense to you?
> 
> It does; but it might make sense to add a comment explaining that.

Sure thing. I'll add a sentence or three on the subject.

> Userspace should hopefully be able to just map everything to RAS == V1P1
> and be done with it.

Indeed, that's the intention. RAS_frac is zeroed and made
non-writable.  This is also consistent with RASv2, for which RAS_frac
is not relevant (not that there is a plan to support RASv2 in the
foreseeable future!).

Thanks,

	M.

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