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
signature.asc
Description: PGP signature
