All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>, Fuad Tabba <tabba@google.com>
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, 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,
	sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com
Subject: Re: [PATCH v21 05/23] KVM: arm64: Track the type of VM in kvm_arch
Date: Fri, 02 Oct 2026 15:15:06 +0100	[thread overview]
Message-ID: <86pkxs2npx.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTwHuJ0u_TTP46zNFKFmBP124XHHLUVhkAUSyfhe92=41w@mail.gmail.com>

On Fri, 02 Oct 2026 14:05:17 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Marc,
> 
> On Fri, 02 Oct 2026 13:57:11 +0100, Marc Zyngier <maz@kernel.org> wrote:
> [...]
> > Just to make sure. Is that what you had in mind?
> 
> A diff is worth a thousand words :) Yes, that's it. With that, every
> remaining hyp user of vcpu_is_protected() only runs with pKVM, so the
> kern_hyp_va() case in the macro can go too.

Actually, scratch all of that. The whole thing is written upside down,
and makes little sense. I wish I had looked at it more closely...

The *_protected__pkvm() shouldn't exist at all, because nVHE is the
only context where it matters, and therefore we can specialise the
*normal* accessors for the nVHE context (see below). No *_pkvm(), no
kern_hyp_va(), nothing at all.

I'm also dead against the unprotected_pkvm() stuff, as it looks
pointlessly specialised. Specifically, this nugget is making my head
spin:

+       if (!kvm_vm_is_unprotected_pkvm(vcpu->kvm))
                return;

Honestly, we introduce the flavor stuff to make it easy to match
things on a particular VM type in a readable way. So why isn't this
reading:

	if (vcpu->kvm->arch.vm_flavor != VM_PROTECTED_PKVM)
		return;

which makes it pretty explicit. You can gate it with a
is_protected_kvm_enabled() if you want, as it was before.

	M.


diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 9e1fa00d96f7c..6b64f9610f3a3 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -1519,41 +1519,22 @@ struct kvm *kvm_arch_alloc_vm(void);
 
 #define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE
 
-#define kvm_vm_is_protected(kvm)	((kvm)->arch.vm_flavor >= __VM_PROTECTED)
-/*
- * 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.
- */
-#define vcpu_is_protected(vcpu)						\
-	({								\
-		struct kvm *__kvm = READ_ONCE((vcpu)->kvm);		\
-		bool __protected = false;				\
-									\
-		if (__kvm) {						\
-			if (is_nvhe_hyp_code() &&			\
-			    !is_protected_kvm_enabled()) 		\
-				__kvm = kern_hyp_va(__kvm); 		\
-									\
-			__protected = kvm_vm_is_protected(__kvm);	\
-		}							\
-		__protected;						\
-	})
-
-#define kvm_vm_is_protected_pkvm(kvm)					\
+#ifdef __KVM_NVHE_HYPERVISOR__
+#define kvm_vm_is_protected(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)					\
+#define vcpu_is_protected(vcpu)						\
 	({								\
 		struct kvm *__kvm = READ_ONCE((vcpu)->kvm);		\
-									\
-		(__kvm && kvm_vm_is_protected_pkvm(__kvm));		\
+		(__kvm && kvm_vm_is_protected(__kvm));			\
 	})
-
+#else
+#define kvm_vm_is_protected(kvm)	((kvm)->arch.vm_flavor >= __VM_PROTECTED)
+#define vcpu_is_protected(vcpu)		kvm_vm_is_protected((vcpu)->kvm)
+#endif
 
 #define kvm_vm_is_unprotected_pkvm(kvm)		\
 	(is_protected_kvm_enabled() && ((kvm)->arch.vm_flavor == VM_PKVM))
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0f4e8b71fa85d..9ba86450fe4af 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2624,7 +2624,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 	hva_t hva, reg_end;
 	int ret = 0;
 
-	if (kvm_vm_is_protected_pkvm(kvm)) {
+	if (kvm_vm_is_protected(kvm)) {
 		/* Cannot modify memslots once a pVM has run. */
 		if (pkvm_hyp_vm_is_created(kvm) &&
 		    (change == KVM_MR_DELETE || change == KVM_MR_MOVE)) {

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

  parent reply	other threads:[~2026-10-02 14:15 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 21:06 [PATCH v21 00/23] KVM: arm64: CCA: Add basic plumbing for Realms Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 01/23] KVM: arm64: protected VM: Handle user writes to CNTVCT_EL0/CNTPCT_EL0 Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 02/23] KVM: arm64: Disable Steal time accounting for protected guests Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 03/23] KVM: arm64: Include kvm_emulate.h in kvm/arm_psci.h Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 04/23] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 05/23] KVM: arm64: Track the type of VM in kvm_arch Suzuki K Poulose
2026-10-02 10:06   ` Fuad Tabba
2026-10-02 12:57     ` Marc Zyngier
2026-10-02 13:05       ` Fuad Tabba
2026-10-02 13:10         ` Suzuki K Poulose
2026-10-02 13:34         ` Marc Zyngier
2026-10-02 14:15         ` Marc Zyngier [this message]
2026-10-02 14:37           ` Fuad Tabba
2026-10-02 15:29             ` Marc Zyngier
2026-10-02 15:30               ` Fuad Tabba
2026-10-03  5:53               ` Suzuki K Poulose
2026-10-03  7:07                 ` Suzuki K Poulose
2026-10-03  8:45                   ` Marc Zyngier
2026-10-02 15:15           ` Suzuki K Poulose
2026-10-02 15:40             ` Marc Zyngier
2026-10-02 15:42               ` Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 06/23] KVM: arm64: Don't call vcpu_set_pauth_traps for pKVM host Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 07/23] KVM: arm64: Refactor the vcpu_load to allow for VM specific callbacks Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 08/23] KVM: arm64: Add vcpu load/put call backs for flavors Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 09/23] KVM: arm64: Reuse kvm_stage2_unmap_range in kvm_unmap_gfn_range Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 10/23] KVM: arm64: Add VM specific callback for S2 MMU operations Suzuki K Poulose
2026-10-02 10:19   ` Fuad Tabba
2026-10-02 10:29     ` Suzuki K Poulose
2026-10-03  9:01   ` Marc Zyngier
2026-10-03 15:30     ` Suzuki K Poulose
2026-10-03 16:12       ` Suzuki K Poulose
2026-10-03 17:32         ` Marc Zyngier
2026-10-01 21:06 ` [PATCH v21 11/23] KVM: arm64: Use a local kvm pointer in kvm_handle_guest_abort() Suzuki K Poulose
2026-10-02  9:14   ` Fuad Tabba
2026-10-01 21:06 ` [PATCH v21 12/23] KVM: arm64: Abstract out memory abort handling Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 13/23] KVM: arm64: Mandate VGIC v3 for pKVM VMs and Realms Suzuki K Poulose
2026-10-02  9:23   ` Fuad Tabba
2026-10-01 21:06 ` [PATCH v21 14/23] KVM: arm64: CCA: Add a new mode for supporting Realm guests Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 15/23] KVM: arm64: CCA: Add VCPU load/put for Realms Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 16/23] KVM: arm64: CCA: Add bare minimal S2 operations for Realm Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 17/23] KVM: arm64: CCA: Introduce Realms Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 18/23] KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests Suzuki K Poulose
2026-10-02  9:13   ` sashiko-bot
2026-10-02  9:20     ` Suzuki K Poulose
2026-10-02  9:34   ` Fuad Tabba
2026-10-02  9:36     ` Suzuki K Poulose
2026-10-01 21:06 ` [PATCH v21 19/23] KVM: arm64: Prevent unsupported vcpu features for VM types Suzuki K Poulose
2026-10-01 21:07 ` [PATCH v21 20/23] KVM: arm64: CCA: WARN on injected undef exceptions Suzuki K Poulose
2026-10-01 21:07 ` [PATCH v21 21/23] KVM: arm64: CCA: Support timers in realm RECs Suzuki K Poulose
2026-10-01 21:07 ` [PATCH v21 22/23] KVM: arm64: CCA: Expose SVE VL register before VCPU finalization Suzuki K Poulose
2026-10-02  9:13   ` sashiko-bot
2026-10-01 21:07 ` [PATCH v21 23/23] KVM: arm64: CCA: Control user register access for Realms Suzuki K Poulose
2026-10-01 21:41 ` [PATCH v21 00/23] KVM: arm64: CCA: Add basic plumbing " Gavin Shan
2026-10-02  6:13   ` Suzuki K Poulose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86pkxs2npx.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=WeiLin.Chang@arm.com \
    --cc=alpergun@google.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=enju.kohei@fujitsu.com \
    --cc=fj0570is@fujitsu.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=gshan@redhat.com \
    --cc=joey.gouly@arm.com \
    --cc=jonathan.cameron@oss.qualcomm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sdonthineni@nvidia.com \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.