Re: [PATCH v6 8/9] KVM: arm64: Check whether a VM IOCTL is allowed in pKVM

Hi Marc,

On Thu, 15 Jan 2026 at 15:03, Marc Zyngier [off-list ref] wrote:

On Thu, 11 Dec 2025 10:47:08 +0000,
Fuad Tabba [off-list ref] wrote:

quoted

Certain VM IOCTLs are tied to specific VM features. Since pKVM does not
support all features, restrict which IOCTLs are allowed depending on
whether the associated feature is supported.

Use the existing VM capability check as the source of truth to whether
an IOCTL is allowed for a particular VM by mapping the IOCTLs with their
associated capabilities.

Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
---
 arch/arm64/include/asm/kvm_pkvm.h | 21 +++++++++++++++++++++
 arch/arm64/kvm/arm.c              |  3 +++
 2 files changed, 24 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
index 5b564576160d..0fa8c84816fd 100644
--- a/arch/arm64/include/asm/kvm_pkvm.h
+++ b/arch/arm64/include/asm/kvm_pkvm.h

@@ -9,6 +9,7 @@
 #include <linux/arm_ffa.h>
 #include <linux/memblock.h>
 #include <linux/scatterlist.h>
+#include <asm/kvm_host.h>
 #include <asm/kvm_pgtable.h>

 /* Maximum number of VMs that can co-exist under pKVM. */

@@ -43,6 +44,7 @@ static inline bool kvm_pkvm_ext_allowed(struct kvm *kvm, long ext)
      case KVM_CAP_ARM_SVE:
      case KVM_CAP_ARM_PTRAUTH_ADDRESS:
      case KVM_CAP_ARM_PTRAUTH_GENERIC:
+     case KVM_CAP_ARM_BASIC:

Can we instead rely on an existing VM capability? I'm not overly keen
exposing something new to userspace (KVM_CAP_ARM_BASIC) for something
that really is KVM's own internal problems.

Looking at the history, a bunch of things have always been present:
KVM_CAP_NR_VCPUS, for example. You could even #define
KVM_CAP_ARM_BASIC to that if you want.

I wasn't too crazy about that either. I like the idea of defining it
as an alias of KVM_CAP_NR_VCPUS. I'll do that when I respin.

Cheers,
/fuad

Thanks,

        M.

--
Without deviation from the norm, progress is not possible.