On Mon, 21 Jul 2025 14:12:19 +0100, Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > On Mon, Jul 21 2025, Marc Zyngier <maz@xxxxxxxxxx> wrote: > > > On Mon, 21 Jul 2025 13:32:08 +0100, > > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > >> > >> On Mon, Jul 21 2025, Marc Zyngier <maz@xxxxxxxxxx> 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.
