Re: [PATCH v16 29/45] KVM: arm64: CCA: Support runtime faulting of memory

On 11/08/2026 16:42, Catalin Marinas wrote:

On Mon, Aug 03, 2026 at 02:43:45PM +0100, Steven Price wrote:

quoted

At runtime if the realm guest accesses memory which hasn't yet been
mapped then KVM needs to either populate the region or fault the guest.

For memory in the lower (protected) region of IPA a fresh page is
provided to the RMM which will zero the contents. For memory in the
upper (shared) region of IPA, the memory from the memslot is mapped
into the realm VM non secure.

Is this still true with in-place guestmem conversion?

quoted

@@ -1693,7 +1709,14 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
  	kvm_fault_lock(kvm);
  	if (mmu_invalidate_retry(kvm, mmu_seq)) {
  		ret = -EAGAIN;
-		goto out_unlock;
+		goto out_release_page;
+	}
+
+	if (kvm_is_realm(kvm)) {
+		prot &= ~KVM_PGTABLE_PROT_X;
+		ret = realm_map_ipa(kvm, s2fd->fault_ipa, pfn,
+				    PAGE_SIZE, prot, memcache);
+		goto out_release_page;
  	}

[...]

quoted

+int realm_map_ipa(struct kvm *kvm, phys_addr_t ipa,
+		  kvm_pfn_t pfn, unsigned long map_size,
+		  enum kvm_pgtable_prot prot,
+		  struct kvm_mmu_memory_cache *memcache)
+{
+	struct realm *realm = &kvm->arch.realm;
+
+	ipa = ALIGN_DOWN(ipa, map_size);
+	if (!kvm_realm_is_private_address(realm, ipa)) {
+		return realm_map_non_secure(kvm, ipa, pfn, map_size, prot,
+					    memcache);
+	}
+
+	/* It's impossible to map protected pages read-only. */
+	if (WARN_ON(!(prot & KVM_PGTABLE_PROT_W)))
+		return -EFAULT;
+	return realm_map_protected(kvm, ipa, pfn, map_size, memcache);
+}

I was trying to understand (with the help of some LLMs) to understand
whether we can end up on the do_gpf() path as a result of VMM actions.
The above kvm_realm_is_private_address() only checks for the IPA but
does not check against guestmem if the page is truly private. I probably
miss something but the scenario would be something like:

1. VMM creates the gmem region with GUEST_MEMFD_FLAG_MMAP |
    GUEST_MEMFD_FLAG_INIT_SHARED, mmap()able and GUP-pinnable

2. VMM starts an O_DIRECT write() from that mapping; the block layer
    FOLL_PINs the shared folio

3. VMM runs a vCPU so the realm touches the protected-IPA alias of the
    same gfn. gmem_abort() delegates the pinned, still-shared page to
    the RMM

4. The in-flight I/O then reads the now-Realm page from the kernel
    linear map. That access takes a GPF at EL1, so do_gpf() ->
    die_kernel_fault()

This is correct. The fundamental issue is that we have a disconnect
between the "gmem attribute" changes (to private/shared) and the
RIPAS and this is something we want to fix.

e.g., the KVM CCA driver sets the entire DRAM to RIPAS_RAM for
the Realm before ACTIVATION and we expect that the VMM changes
the gmem to PRIVATE. They both are not in sync. his is something
we were discussing the other day with Aneesh.

Once they are in sync, we are protected. If the RIPAS=EMPTY
(gmem=shared) a stage2 fault doesn't come to the Host.

If the RIPAS=RAM, the gmem is private and there are no usespace
mappings.

The reason why it is disconnected at the moment is due to the
weird semantics for Guest triggered conversions in CCA
i.e., Realm requests via RSI_IPA_STATE_SET, triggering a RIPAS_CHANGE
exit to the KVM.

The KVM exits to VMM with MEMORY_FAULT_EXIT and the VMM can service this
by invoking GMEM(SET_ATTRIBUTES2). But, the KVM needs to invoke the
RMI_RTT_SET_RIPAS in the context of the "vcpu", which we don't have
from the "kvm" context. I guess we can fix it by running through the
vcpus and find the matching one with the "ipa" range and the "ripas".

And as for the VMM requests before the Realm is activated, we could
map that to RMI_RTT_INIT_RIPAS and removing the implicit change
from KVM arm64.


Thanks
Suzuki

x86, IIUC, also checks kvm_gmem_is_private(). They also have
kvm_arch_gmem_make_private() triggered on the kvm_gmem_get_pfn() path
but I got lost in the call sites, not sure whether that's strictly
needed if we check both private IPA and kvm_gmem_is_private().