Thread (178 messages) 178 messages, 11 authors, 2022-06-06

Re: [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the RMP fault for user address

From: Vlastimil Babka <hidden>
Date: 2021-07-30 16:00:23
Also in: linux-coco, linux-crypto, linux-efi, linux-mm, lkml, platform-driver-x86

On 7/7/21 8:35 PM, Brijesh Singh wrote:
quoted hunk ↗ jump to hunk
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4407,6 +4407,15 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf)
 	return 0;
 }
 
+static int handle_split_page_fault(struct vm_fault *vmf)
+{
+	if (!IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT))
+		return VM_FAULT_SIGBUS;
+
+	__split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
+	return 0;
+}
+
I think back in v1 Dave asked if khugepaged will just coalesce this back, and it
wasn't ever answered AFAICS.

I've checked the code and I think the answer is: no. Khugepaged isn't designed
to coalesce a pte-mapped hugepage back to pmd in place. And the usual way (copy
to a new huge page) I think will not succeed because IIRC the page is also
FOLL_PIN pinned and  khugepaged_scan_pmd() will see the elevated refcounts via
is_refcount_suitable() and give up.

So the lack of coalescing (in case the sub-page leading to split becomes guest
private again later) is somewhat suboptimal, but not critical.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help