Re: [PATCH 10/11] KVM: arm64: CCA: Support runtime faulting of memory

From: Suzuki K Poulose

Date: Mon Nov 09 2026 - 06:39:40 EST


Hi Fuad

Thanks for sharing the pVM gmem details, some more questions below.

On 09/11/2026 07:40, Fuad Tabba wrote:
Hi Suzuki, Steve,

On Thu, 05 Nov 2026 17:30:16 +0000, Suzuki K Poulose
<suzuki.poulose@xxxxxxx> wrote:
[...]
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
[...]
@@ -1816,13 +1828,28 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd,
/* Pairs with the smp_wmb() in kvm_mmu_invalidate_end(). */
smp_rmb();

+ if (kvm_vm_is_realm(kvm)) {
+ is_realm_private = kvm_realm_is_private_address(&kvm->arch.realm,
+ s2fd->fault_ipa);
+
+ if (is_realm_private != kvm_gmem_is_private_gfn(kvm, canonical_gfn)) {
[...]
I am wondering there is a way to make it a bit more generic. The issue
is, only Realm has private memory with guest_memfd for now. Don't know
the pKVM plans for it.

The plan is for protected pKVM VMs to be backed by guest_memfd too,
which would also hold each page's private/shared state [1]. So
kvm_arch_has_private_mem() will be true for them, and this comparison
applies as is. Only how the expected state is computed differs: for a
pVM it comes from the per-page share state rather than an IPA bit.

When you say, per-page, you mean per-IPA or per "backing page" ? i.e.,
can pKVM do something like :

kvm_ipa_is_private(kvm, ipa) ?

(similar to Realm) or does it need the struct page backing the "ipa" ?


Steve, could you gate the guest_memfd checks on
kvm_arch_has_private_mem(kvm) rather than kvm_vm_is_realm(), this one
and the memslot check you proposed for 02/11? Only the
kvm_realm_is_private_address() and realm_map_ipa() calls are
realm-specific, and they could be VM_REALM cases of a switch on
vm_flavor, as Marc asked for on the v21 memslot check [2]. The macro
would then only widen to protected VMs when pKVM's guest_memfd support

Makes sense.

Suzuki

lands.

Cheers,
/fuad

[1] https://lore.kernel.org/all/CA+EHjTz+WgXEW5RTxXf4oGeEb1Tsm5Ha4nOc4S1jBcp7jxP4+A@xxxxxxxxxxxxxx/
[2] https://lore.kernel.org/all/86mrsw2jrn.wl-maz@xxxxxxxxxx/