Messages in this thread | | | Subject | Re: [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the RMP fault for user address | From | Brijesh Singh <> | Date | Mon, 12 Jul 2021 11:24:16 -0500 |
| |
On 7/12/21 11:15 AM, Dave Hansen wrote: > On 7/12/21 9:11 AM, Brijesh Singh wrote: >>> Please fix this code to handle hugetlbfs along with any other non-THP >>> source of level>0 mappings. DAX comes to mind. "Handle" can mean >>> rejecting these. You don't have to find some way to split them and make >>> the VM work, just fail safely, ideally as early as possible. >>> >>> To me, this is a fundamental requirement before this code can be >>> accepted. >> >> Understood, if userspace decided to use the hugetlbfs backing pages then >> I believe earliest we can detect is when we go about adding the pages in >> the RMP table. I'll add a check, and fail the page state change. > > Really? You had to feed the RMP entries from *some* mapping in the > first place. Is there a reason the originating mapping can't be checked > at that point instead of waiting for the fault? >
Apologies if I was not clear in the messaging, that's exactly what I mean that we don't feed RMP entries during the page state change.
The sequence of the operation is:
1. Guest issues a VMGEXIT (page state change) to add a page in the RMP 2. Hyperivosr adds the page in the RMP table.
The check will be inside the hypervisor (#2), to query the backing page type, if the backing page is from the hugetlbfs, then don't add the page in the RMP, and fail the page state change VMGEXIT.
-Brijesh
| |