http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.232.135.74 listed in list.dnswl.org] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 Hi Fuad, On Thu, 12 Feb 2026 09:02:50 +0000, Fuad Tabba wrote: > > When CONFIG_ARM64_POE is disabled, KVM does not save/restore POR_EL1. > However, ID_AA64MMFR3_EL1 sanitisation currently exposes the feature to > guests whenever the hardware supports it, ignoring the host kernel > configuration. This is the umpteenth time we get caught by this. PAN was the latest instance until this one. Maybe an approach would be to have a default override when a config option is not enabled, so that KVM is consistent with the rest of the kernel? > > If a guest detects this feature and attempts to use it, the host will > fail to context-switch POR_EL1, potentially leading to state corruption. > > Fix this by masking ID_AA64MMFR3_EL1.S1POE and preventing KVM from > advertising the feature when the host does not support it, i.e., > system_supports_poe() is false. > > Fixes: 70ed7238297f ("KVM: arm64: Sanitise ID_AA64MMFR3_EL1") > Signed-off-by: Fuad Tabba > --- > arch/arm64/include/asm/kvm_host.h | 3 ++- > arch/arm64/kvm/sys_regs.c | 3 +++ > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index ac7f970c7883..7af72ca749a6 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -1592,7 +1592,8 @@ void kvm_set_vm_id_reg(struct kvm *kvm, u32 reg, u64 val); > (kvm_has_feat((k), ID_AA64MMFR3_EL1, S1PIE, IMP)) > > #define kvm_has_s1poe(k) \ > - (kvm_has_feat((k), ID_AA64MMFR3_EL1, S1POE, IMP)) > + (system_supports_poe() && \ > + kvm_has_feat((k), ID_AA64MMFR3_EL1, S1POE, IMP)) Why do we need to further key this on system_supports_poe()? I can see this is a potential optimisation, but I don't think this is part of the minimal fix. > > #define kvm_has_ras(k) \ > (kvm_has_feat((k), ID_AA64PFR0_EL1, RAS, IMP)) > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 88a57ca36d96..237e8bd1cf29 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1816,6 +1816,9 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, > ID_AA64MMFR3_EL1_SCTLRX | > ID_AA64MMFR3_EL1_S1POE | > ID_AA64MMFR3_EL1_S1PIE; > + > + if (!system_supports_poe()) > + val &= ~ID_AA64MMFR3_EL1_S1POE; How about S1PIE? It seems to have a similar problem, in the sense that it has extra state. But I guess because we don't put it behind a config option, we context-switch it anyway and all is good? Thanks, M. -- Without deviation from the norm, progress is not possible. From - Thu Feb 12 17:52:47 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id CA3MFB8QjmnnSzYAYBR5ng (envelope-from ) for ; Thu, 12 Feb 2026 17:38:39 +0000 Return-path: Envelope-to: hi@josie.lo