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
