[PATCH v12 22/29] KVM: arm64: Context switch SME state for guests

[Mark Brown]

On Sun, Jul 12, 2026 at 03:40:34PM +0100, Fuad Tabba wrote:

> For a nested guest this folds in the LEN restriction from the guest
> hypervisor's SMCR_EL2 just above, but not FA64/EZT0. vcpu_has_fa64()
> and vcpu_has_sme2() are VM-level capabilities (kvm_has_fa64/sme2 on
> vcpu->kvm), so an L1 that clears SMCR_EL2.FA64 or .EZT0 to deny them to
> L2 is overridden here: the physical SMCR_EL2 gets the bits set from the
> VM cap regardless.

Doh, of course.  I've fixed this locally.

> > @@ -128,7 +220,7 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
> >  {
> >         struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
> >
> > -       fpsimd_sve_flush();
> > +       fpsimd_sve_flush(host_vcpu);
> 
> sync_hyp_vcpu() runs fpsimd_sve_sync() on &hyp_vcpu->vcpu, but flush
> passes host_vcpu, so the two sides operate on different vCPUs. That
> asymmetry alone looks wrong: flush and sync should cover the same
> state.
> 
> Concretely it means kvm_sme_configure_traps() programs a protected
> guest's SVCR/SMCR from host-owned values, so the host can e.g. set
> SVCR.SM and fault the guest. Keying flush off &hyp_vcpu->vcpu like
> sync fixes both.

Thanks for spotting that, I've updated locally.

BTW it'd be really helpful to delete unneeded context when replying
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260713/3c9e8f41/attachment.sig>