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

[Julien Grall <julien.grall@xxxxxxx>]

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, <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>
Release-acked-by: Julien Grall <julien.grall@xxxxxxx>

Cheers,

--
Julien Grall

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