From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDA3149E5D0; Fri, 11 Sep 2026 16:14:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789143271; cv=none; b=uganEGkBdZFd6Zn303U1bs0zhbo+sPcInlBOWFECV/kNnBV1jE79Se+9j8DYb01qAncQ+lR98HonmLYJWDO6V72SQUee0QWP0yUV0RJNTzfl8RS6mXmOItUBUPC2HqLs2rLkm+y73BYE8xVZ14v/d4AhVvj/5jbyXn881XPoF50= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789143271; c=relaxed/simple; bh=4GQBiBIo+qcJsJlKDNYaahbdSDXXKK0YlvpfTJ8GarI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=oXc43a4yN9CI4/DX/1qvYZh77Y+9MxEicke/aRrp5ldvxGajls1GL7LKLZ0gYkViBF4D/2Alxwkbh5519cYXXRBbXmAQO6US1qif8/H8OeQ3RQC3GnVnm52ru/9s0o24MzXqVQRZhV+6IOB+WRQvRNTeg42itywts2wI2R8J338= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nhLJkpW8; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nhLJkpW8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA15B1F00898; Fri, 11 Sep 2026 16:14:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789143269; bh=hHOxwJzdAOdqO5u2s6Tk+2w3Xe4vyjxHhTA47EDAalw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=nhLJkpW8p1NUcjeRDycANyW1eSFa2JlEyTfLerpmub7R6YEfUxNSdUrm6xNF2eZOy TRdx/N8VZfMtQifNxw1m1TkbgnMC1OIc7/qMhZbx0ke5zsQQCRx7zu3nuR+sN3S9B7 Tx1u/rlTY/k4ObYn//tTOnmBPv6YVCY2wHsc/dymkLZ9FBO7MsHxi6ADi06Vaaobro E3mEGIfLS+jjfzBiMx14C5bEpCvnyoIvEiTsx374Fl4elQWfGtAnxPc8S8d8i+g4gF L5WXaoOdHjd0G94mDOICUaNs7qa1DlUQ1ragp+UqGqXRzBXboS74dt4pEXPyg440Ay I7UUS+xCxqvvw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x53tT-00000007qHf-2NtI; Fri, 11 Sep 2026 16:14:27 +0000 Date: Fri, 11 Sep 2026 17:14:27 +0100 Message-ID: <86fqzf7okc.wl-maz@kernel.org> From: Marc Zyngier To: Suzuki K Poulose Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, steven.price@arm.com, aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com, joey.gouly@arm.com, tabba@google.com, yuzenghui@huawei.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, sdonthineni@nvidia.com, alpergun@google.com, fj0570is@fujitsu.com, WeiLin.Chang@arm.com, lpieralisi@kernel.org, enju.kohei@fujitsu.com Subject: Re: [PATCH v17 03/20] KVM: arm64: Track the type of VM in kvm_arch In-Reply-To: <20260908162223.1683432-4-suzuki.poulose@arm.com> References: <20260908162223.1683432-1-suzuki.poulose@arm.com> <20260908162223.1683432-4-suzuki.poulose@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: suzuki.poulose@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, steven.price@arm.com, aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com, joey.gouly@arm.com, tabba@google.com, yuzenghui@huawei.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, sdonthineni@nvidia.com, alpergun@google.com, fj0570is@fujitsu.com, WeiLin.Chang@arm.com, lpieralisi@kernel.org, enju.kohei@fujitsu.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 08 Sep 2026 17:22:06 +0100, Suzuki K Poulose 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 > friendlier 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. (e.g., protected on !PKVM) > > With that, use the vm_flavor to detect if a VM is protected VM on PKVM. > > Based on a patch by Marc Zyngier > > Suggested-by: Marc Zyngier > Signed-off-by: Suzuki K Poulose > --- > arch/arm64/include/asm/kvm_host.h | 12 ++++++++++-- > arch/arm64/kvm/arm.c | 27 ++++++++++++++++++++++++--- > arch/arm64/kvm/hyp/nvhe/pkvm.c | 2 +- > arch/arm64/kvm/pkvm.c | 1 - > 4 files changed, 35 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 27fe0cd5b2d7a..d0dccc9ad6aa8 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,18 @@ enum fgt_group_id { > __NR_FGT_GROUP_IDS__ > }; > > +enum kvm_arm_vm_flavor { > + VM_NVHE, > + VM_VHE, > + VM_PKVM, /* Normal guests on PKVM */ > + VM_PROTECTED_PKVM, /* Protected VM */ > + VM_FLAVOR_MAX, > +}; > + My original design did introduce classes of VMs, which I definitely want to retain so that we don't pointlessly differentiate CCA VMs from pKVM protected guests when at all possible. Realms are protected VMs, full stop. With that in mind, this should read: enum kvm_arm_vm_flavor { VM_NVHE, VM_VHE, VM_PKVM, /* Normal guests on PKVM */ MARKER(__VM_FLAVOR_PROTECTED__), VM_PROTECTED_PKVM, /* Protected VM */ VM_REALM, /* CCA */ VM_FLAVOR_MAX, }; > struct kvm_arch { > struct kvm_s2_mmu mmu; > > + enum kvm_arm_vm_flavor vm_flavor; > /* > * Fine-Grained UNDEF, mimicking the FGT layout defined by the > * architecture. We track them globally, as we present the > @@ -1504,7 +1512,7 @@ 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_PKVM) and this should read ((kvm)->arch.vm_flavor >= __VM_FLAVOR_PROTECTED__). Thanks, M. -- Without deviation from the norm, progress is not possible.