Re: [Xen-devel] [PATCH] x86/NPT: deal with fallout from 2Mb/1Gb unmapping change

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 24/05/17 17:57, Boris Ostrovsky wrote:
> On 05/24/2017 06:21 AM, Jan Beulich wrote:
>>>>> On 24.05.17 at 11:14, <JBeulich@xxxxxxxx> wrote:
>>> Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
>>> pages") left the NPT code untouched, as there is no explicit alignment
>>> check matching the one in EPT code. However, the now more widespread
>>> storing of INVALID_MFN into PTEs requires adjustments:
>>> - calculations when shattering large pages may spill into the p2m type
>>>   field (converting p2m_populate_on_demand to p2m_grant_map_rw) - use
>>>   OR instead of PLUS,
> 
> Would it be possible to just skip filling the entries if p2m_entry
> points to an INVALID_MFN?

No, because we still want to know the type of the entry, even though the
pfn is INVALID.

> 
> If not, I think a comment explaining the reason for using '|' would be
> useful.
> 
> 
>>> - the use of plain l{2,3}e_from_pfn() in p2m_pt_set_entry() results in
>>>   all upper (flag) bits being clobbered - introduce and use
>>>   p2m_l{2,3}e_from_pfn(), paralleling the existing L1 variant.
>>>
>>> Reported-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Tested-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel