summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorOliver Upton <oliver.upton@linux.dev>2023-06-09 21:00:46 +0200
committerOliver Upton <oliver.upton@linux.dev>2023-06-13 01:08:33 +0200
commit2251e9ff1573a266102f40e507f0b8dc5861f3e4 (patch)
tree8f6e8edd82f4c8e6bb827c6066b7fed7adf03655 /include
parentKVM: arm64: Relax invariance of KVM_ARM_VCPU_POWER_OFF (diff)
downloadlinux-2251e9ff1573a266102f40e507f0b8dc5861f3e4.tar.xz
linux-2251e9ff1573a266102f40e507f0b8dc5861f3e4.zip
KVM: arm64: Make vCPU feature flags consistent VM-wide
To date KVM has allowed userspace to construct asymmetric VMs where particular features may only be supported on a subset of vCPUs. This wasn't really the intened usage pattern, and it is a total pain in the ass to keep working in the kernel. What's more, this is at odds with CPU features in host userspace, where asymmetric features are largely hidden or disabled. It's time to put an end to the whole game. Require all vCPUs in the VM to have the same feature set, rejecting deviants in the KVM_ARM_VCPU_INIT ioctl. Preserve some of the vestiges of per-vCPU feature flags in case we need to reinstate the old behavior for some limited configurations. Yes, this is a sign of cowardice around a user-visibile change. Hoist all of the 32-bit limitations into kvm_vcpu_init_check_features() to avoid nested attempts to acquire the config_lock, which won't end well. Link: https://lore.kernel.org/r/20230609190054.1542113-4-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions