Hi George,
On 05/06/17 12:40, George Dunlap wrote:
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, <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?
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.ostrov...@oracle.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Tested-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
Acked-by: George Dunlap <george.dun...@citrix.com>
Release-acked-by: Julien Grall <julien.gr...@arm.com>
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
