Thread (82 messages) 82 messages, 7 authors, 2024-12-02

Re: [PATCH v5 17/43] arm64: RME: Allow VMM to set RIPAS

From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
Date: 2024-10-30 07:52:09
Also in: kvm, kvmarm, linux-coco, lkml

Suzuki K Poulose [off-list ref] writes:
Hi Steven

quoted
+	if (WARN_ON(rmi_granule_undelegate(phys))) {
+		/* Undelegate failed: leak the page */
+		return;
+	}
+
+	free_page((unsigned long)phys_to_virt(phys));
The above pattern of undelegate and reclaim a granule or leak appears 
elsewhere in the KVM support code. Is it worth having a common helper to
do the same ?

something like: reclaim_delegated_granule()
free_delegated_page() which should really be renamed to
free_delegated_granule() essentially does that.

IMHO we should convert all the delgated allocation and free to
alloc_delegated_granule() and free_delegated_granule(). This will also
help in switching to a slab for granule allocation. 
quoted
+}
+
+static int realm_rtt_create(struct realm *realm,
+			    unsigned long addr,
+			    int level,
+			    phys_addr_t phys)
+{
+	addr = ALIGN_DOWN(addr, rme_rtt_level_mapsize(level - 1));
+	return rmi_rtt_create(virt_to_phys(realm->rd), phys, addr, level);
+}
.......
quoted
+static void realm_unmap_range_private(struct kvm *kvm,
+				      unsigned long start,
+				      unsigned long end)
+{
+	struct realm *realm = &kvm->arch.realm;
+	ssize_t map_size = RME_PAGE_SIZE;
+	unsigned long next_addr, addr;
+
+	for (addr = start; addr < end; addr = next_addr) {
+		int ret;
+
+		next_addr = ALIGN(addr + 1, map_size);
+
Is that next_addr update needed? 

quoted
+		ret = realm_destroy_protected(realm, addr, &next_addr);
+
+		if (WARN_ON(ret))
+			break;
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help