On 7/7/21 8:35 PM, Brijesh Singh wrote:
> --- 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.
