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

[Brijesh Singh]

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