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@xxxxxxxxxx> > > --- > > 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
