lkml.org 
[lkml]   [2021]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the RMP fault for user address
From
Date


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

\
 
 \ /
  Last update: 2021-07-12 18:24    [W:0.995 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site