[PATCH 0/4] KVM: arm64: pKVM SVE vCPU init fixes

Fuad Tabba <[email protected]>
Newsgroups org.infradead.lists.linux-arm-kernel,dev.linux.lists.kvmarm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Hi folks,

If it's not the GIC, it's SVE. I found these while preparing the
follow-up to the pKVM core series [1].

Patch 1 was posted on its own [2] and carries Marc's Reviewed-by. It is
unchanged and included here because it has not been picked up yet and
the rest of the series does not apply without it.

Patches 2 and 4 are two ways to reach the same broken state, a vCPU
whose sve_state is NULL while vcpu_has_sve() is true, so the world
switch loads the guest's SVE state from it. EL2 keeps two answers to
"does this guest have SVE": KVM_ARCH_FLAG_GUEST_HAS_SVE, which the
world switch reads, and KVM_ARM_VCPU_SVE, which pkvm_vcpu_init_sve()
reads. Patch 2 stops EL2 desynchronising them itself on an init
failure. Patch 4 stops the host handing them over already
desynchronised. Patch 3 keys the unpin on the state it unpins rather
than on the feature bit, which agree for any vCPU that completed init.

All of it needs a host that misreports its own vCPU state, so none of
it is reachable from host userspace.

Based on Linux 7.2, and applies cleanly to kvmarm/next.

Cheers,
/fuad

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/

Fuad Tabba (4):
  KVM: arm64: Validate the SVE vector length in pkvm_vcpu_init_sve()
  KVM: arm64: Do not clear VM-wide SVE feature on vCPU init failure
  KVM: arm64: Key unpin_host_sve_state() on the state it unpins
  KVM: arm64: Derive GUEST_HAS_SVE from the SVE feature bit at EL2

 arch/arm64/kvm/hyp/nvhe/pkvm.c | 29 +++++++++++++----------------
 1 file changed, 13 insertions(+), 16 deletions(-)

-- 
2.39.5
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.