[PATCH v22 05/23] KVM: arm64: Track the type of VM in kvm_arch
Suzuki K Poulose
suzuki.poulose at arm.com
Tue Oct 6 01:49:24 PDT 2026
On 06/10/2026 09:33, Marc Zyngier wrote:
> On Mon, 05 Oct 2026 10:07:36 +0100,
> Suzuki K Poulose <suzuki.poulose at arm.com> 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 at kernel.org>
>> Tested-by: Gavin Shan <gshan at redhat.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
>> ---
>> 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@kernel.org
>
>
More information about the linux-arm-kernel
mailing list