           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 <tabba@google.com> 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 <tabba@google.com>
> ---
>  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: <stable+bounces-215982-hi=josie.lol@vger.kernel.org>
Delivered-To: hi@josie.lol
Received: from witcher.mxrouting.net
	by witcher.mxrouting.net with LMTP
	id CA3MFB8QjmnnSzYAYBR5ng
	(envelope-from <stable+bounces-215982-hi=josie.lol@vger.kernel.org>)
	for <hi@josie.lol>; Thu, 12 Feb 2026 17:38:39 +0000
Return-path: <stable+bounces-215982-hi=josie.lol@vger.kernel.org>
Envelope-to: hi@josie.lo