Re: [PATCH v22 05/23] KVM: arm64: Track the type of VM in kvm_arch
From: Suzuki K Poulose
Date: Tue Oct 06 2026 - 04:49:53 EST
On 06/10/2026 09:33, Marc Zyngier wrote:
On Mon, 05 Oct 2026 10:07:36 +0100,
Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
KVM arm64 has different types of VMs with all the different modes in which
the hypervisor code can be run. e.g., VHE, nVHE, pKVM etc. Then there is
protected VM and normal VMs with pKVM. We might soon add other types,
e.g., Arm CCA Realm. So in an effort to make the handling of these
different types of VMs a bit more friendly to the eyes, add a VM flavor to
the kvm_arch and we could then add handlers for different operations based
on the VM type.
Keep the flavor initialisation at the beginning to allow for the detection
early enough and fail out on any unsupported requests.
With that, add wrappers for checking the "type" of a VM and replace the
existing users with the new wrappers.
Given we already have the construct of "kvm_vm_is_protected" in the core
KVM code, use that for all confidential compute guests including Realms
that we are about to add. Adds __VM_PROTECTED marker vm flavor to draw the
boundary for "protected VMs". In later patches, we would add Realm VMs,
which would also be classified as protected.
Add a explicit helper to detect if a given VM is a "protected" VM under pKVM.
Change the existing users that precisely want to check the VM type. These
include :
- kvm_arch_prepare_memory_region - For preventing memslot changes after
pVM creation.
All the others are retained as a wider check for confidential guest VMs.
These are:
- kvm_vm_ioctl_set_counter_offset - For disallowing timer offset
configuration
- io_mem_abort for dabt handling without valid syndrome information
Both of which are true for Realms too.
Realms support is restricted to VHE host and thus "kvm_vm_is_protected()"
checks in the pkvm hyp specific code doesn't need to change, as the only
protected guests it deals with is "protected pKVM" guests. To tighten this
init_pkvm_hyp_vm() restricts the hyp copy of the vm_flavor to the ones it
supports.
vcpu_is_protected() usage from nVHE hyp code is tricky, as we need to
convert the vcpu->kvm to the HYP VA before checking the flavor. This
involves kern_hyp_va() usage in asm/kvm_host.h. To avoid build breaks,
include asm/kvm_mmu.h to arm64/kvm/mmio.c.
While at it move the psci_version around to keep the structure packed.
Suggested-by: Marc Zyngier <maz@xxxxxxxxxx>
Tested-by: Gavin Shan <gshan@xxxxxxxxxx>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
---
Changes since v21:
- Drop kern_hyp_va() and restrict nvhe code to always use vcpu_is_protected_pkvm()
- Drop kvm_vm_is_unprotected_pkvm() and open code the check
- Move psci_version field in kvm_arch around to keep the structure packed
---
arch/arm64/include/asm/kvm_host.h | 42 +++++++++++++++++++++++---
arch/arm64/include/asm/kvm_pkvm.h | 4 +--
arch/arm64/kvm/arm.c | 33 ++++++++++++++++----
arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 2 +-
arch/arm64/kvm/hyp/nvhe/pkvm.c | 6 +++-
arch/arm64/kvm/hyp/nvhe/switch.c | 4 +--
arch/arm64/kvm/hyp/nvhe/timer-sr.c | 2 +-
arch/arm64/kvm/mmio.c | 1 +
arch/arm64/kvm/mmu.c | 2 +-
arch/arm64/kvm/pkvm.c | 6 ++--
10 files changed, 79 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 286489a69dff5..dedb5df15a803 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -257,7 +257,6 @@ struct kvm_protected_vm {
pkvm_handle_t handle;
struct kvm_hyp_memcache teardown_mc;
struct kvm_hyp_memcache stage2_teardown_mc;
- bool is_protected;
bool is_created;
/*
@@ -306,9 +305,22 @@ enum fgt_group_id {
__NR_FGT_GROUP_IDS__
};
+enum kvm_arm_vm_flavor {
+ VM_NVHE,
+ VM_VHE,
+ VM_PKVM, /* Normal guests on pKVM */
+ MARKER(__VM_PROTECTED),
+ VM_PROTECTED_PKVM, /* Protected VM */
+ VM_FLAVOR_MAX
+};
+
struct kvm_arch {
struct kvm_s2_mmu mmu;
+ enum kvm_arm_vm_flavor vm_flavor;
+ /* Mandated version of PSCI */
+ u32 psci_version;
+
/*
* Fine-Grained UNDEF, mimicking the FGT layout defined by the
* architecture. We track them globally, as we present the
@@ -332,9 +344,6 @@ struct kvm_arch {
/* Timers */
struct arch_timer_vm_data timer_data;
- /* Mandated version of PSCI */
- u32 psci_version;
-
/* Protects VM-scoped configuration data */
struct mutex config_lock;
@@ -1504,9 +1513,32 @@ struct kvm *kvm_arch_alloc_vm(void);
#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE
-#define kvm_vm_is_protected(kvm) (is_protected_kvm_enabled() && (kvm)->arch.pkvm.is_protected)
+#define kvm_vm_is_protected(kvm) ((kvm)->arch.vm_flavor >= __VM_PROTECTED)
+#ifdef __KVM_NVHE_HYPERVISOR__
+/*
+ * Accessing vcpu->kvm from nVHE hyp stub is tricky, as we need to convert the
+ * pointer to the hyp VA. With pKVM, the nVHE code runs with the hyp_vcpu,
+ * which is populated correctly. Always vcpu_is_protected_pkvm(), which is
Always *use*?
Ack
+ * gated on is_protected_kvm_enabled().
+ */
+#define vcpu_is_protected(vcpu) BUILD_BUG_ON(1)
+#else
#define vcpu_is_protected(vcpu) kvm_vm_is_protected((vcpu)->kvm)
+#endif
+
+#define kvm_vm_is_protected_pkvm(kvm) \
+ (is_protected_kvm_enabled() && ((kvm)->arch.vm_flavor == VM_PROTECTED_PKVM))
+/*
+ * Rely on is_protected_kvm_enabled() check in kvm_vm_is_protected_pkvm() to
+ * make sure the vcpu->kvm is always valid VA in the context
+ */
+#define vcpu_is_protected_pkvm(vcpu) \
+ ({ \
+ struct kvm *__kvm = READ_ONCE((vcpu)->kvm); \
+ \
+ (__kvm && kvm_vm_is_protected_pkvm(__kvm)); \
+ })
But why do we have to have this pkvm-specific stuff? I thought we had
established it is not necessary in [1].
My bad. I need to wear the glasses :-(
I really want to avoid any backend-specific helper, as it really gets
in the way of maintainability.
Agreed. I will fix this. Apologies
Cheers
Suzuki
M.
[1] https://lore.kernel.org/r/86pkxs2npx.wl-maz@xxxxxxxxxx