As I was debugging some RAS-related issues[1], I realised that: - My test box is implementing RASv1p1 - We unconditionally advertise it to guests - Issuing RASv1p1 accesses doesn't end very well - [...] - Profit? The overall goal of this is to allow the RAS support to be downgraded to not much, as we're not implementing anything interesting yet, while still offering the appearance of architecture compliance up to RASv1p1 (everything is RAZ/WI). Along the way, we plug the most glaring holes (HCR_EL2 bits propagated at the wrong spot, HCR_EL2.FIEN not being filtered out). Unusually, this is on top of the DoubleFault2 series, as this is where the problems started. [1] https://lore.kernel.org/r/87tt37ulvf.wl-maz@xxxxxxxxxx Marc Zyngier (7): arm64: Add capability denoting FEAT_RASv1p1 KVM: arm64: Filter out HCR_EL2 bits when running in hypervisor context KVM: arm64: Make RAS registers UNDEF when RAS isn't advertised KVM: arm64: Handle RASv1p1 registers KVM: arm64: Ignore HCR_EL2.FIEN set by L1 guest's EL2 KVM: arm64: Expose FEAT_RASv1p1 in a canonical manner KVM: arm64: Make ID_AA64PFR0_EL1.RAS writable arch/arm64/kernel/cpufeature.c | 24 ++++++++++++++ arch/arm64/kvm/hyp/vhe/switch.c | 19 +++++++++-- arch/arm64/kvm/sys_regs.c | 56 +++++++++++++++++++++++++++------ arch/arm64/tools/cpucaps | 1 + 4 files changed, 88 insertions(+), 12 deletions(-) -- 2.39.2
