On Fri, 08 Aug 2025 23:48:32 +0100, Oliver Upton <oliver.upton@xxxxxxxxx> 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@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? 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.
