On 05/24/2017 06:21 AM, Jan Beulich wrote:
>>>> On 24.05.17 at 11:14, <jbeul...@suse.com> 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?

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.ostrov...@oracle.com>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>

Tested-by: Boris Ostrovsky <boris.ostrov...@oracle.com>


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

Reply via email to