| Message ID | 20230920195036.1169791-6-oliver.upton@linux.dev (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: arm64: Cleanup + fix to vCPU reset, feature flags | expand |
On Wed, 20 Sep 2023 20:50:33 +0100, Oliver Upton <oliver.upton@linux.dev> wrote: > > It would appear that userspace can select the NV feature flag regardless > of whether the system actually supports the feature. Obviously a nested > guest isn't getting far in this situation; let's reject the flag > instead. The current code is definitely odd. We rely on vcpu_has_nv() to return false, meaning that we go all the way and initialise it as an EL1-only guest. Duh. Well-behaved userspace would check the KVM_CAP_ARM_EL2 capability, which isn't upstream yet... :-( Thanks for fixing this. I'll review the series as a whole. M.
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index e40f3bfcb0a1..ef92c2f2de70 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1208,6 +1208,9 @@ static unsigned long system_supported_vcpu_features(void) clear_bit(KVM_ARM_VCPU_PTRAUTH_GENERIC, &features); } + if (!cpus_have_const_cap(ARM64_HAS_NESTED_VIRT)) + clear_bit(KVM_ARM_VCPU_HAS_EL2, &features); + return features; }
It would appear that userspace can select the NV feature flag regardless of whether the system actually supports the feature. Obviously a nested guest isn't getting far in this situation; let's reject the flag instead. Signed-off-by: Oliver Upton <oliver.upton@linux.dev> --- arch/arm64/kvm/arm.c | 3 +++ 1 file changed, 3 insertions(+)