[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7740c06-b1fa-e63a-4b66-8bda5a6e01b4@intel.com>
Date: Fri, 30 Jul 2021 09:31:30 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Vlastimil Babka <vbabka@...e.cz>,
Brijesh Singh <brijesh.singh@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
linux-coco@...ts.linux.dev, linux-mm@...ck.org,
linux-crypto@...r.kernel.org
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
Tom Lendacky <thomas.lendacky@....com>,
"H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Dov Murik <dovmurik@...ux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@....com>,
Borislav Petkov <bp@...en8.de>,
Michael Roth <michael.roth@....com>, tony.luck@...el.com,
npmccallum@...hat.com, brijesh.ksingh@...il.com
Subject: Re: [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the
RMP fault for user address
On 7/30/21 9:00 AM, Vlastimil Babka wrote:
> 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.
I _thought_ this was the whole "PTE mapped THP" bit of code, like
collapse_pte_mapped_thp(). But, looking at it again, I think that code
is just for the huge tmpfs flavor of THP.
Either way, I'm kinda surprised that we don't collapse things in place.
Especially in the early days, there were lots of crazy things that
split THPs. I think even things like /proc/$pid/smaps split them.
In any case, it sounds like SEV-SNP users should probably be advised to
use MADV_NOHUGEPAGE to avoid any future surprises. At least until the
hardware folks get their act together and teach the TLB how to fracture
2M entries properly. :)
Powered by blists - more mailing lists