[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/NPT: deal with fallout from 2Mb/1Gb unmapping change
>>> 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, > - 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> I'm sorry George, I should also have Cc-ed you on this one. Jan > --- a/xen/arch/x86/mm/p2m-pt.c > +++ b/xen/arch/x86/mm/p2m-pt.c > @@ -45,13 +45,20 @@ > #undef page_to_mfn > #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg)) > > -/* We may store INVALID_MFN in l1 PTEs. We need to clip this > - * to avoid trampling over higher-order bits (NX, p2m type, IOMMU flags). We > - * seem to not need to unclip on the return path, as callers are concerned > only > - * with p2m type in such cases. > +/* > + * We may store INVALID_MFN in PTEs. We need to clip this to avoid > trampling > + * over higher-order bits (NX, p2m type, IOMMU flags). We seem to not need > + * to unclip on the read path, as callers are concerned only with p2m type > in > + * such cases. > */ > #define p2m_l1e_from_pfn(pfn, flags) \ > l1e_from_pfn((pfn) & (PADDR_MASK >> PAGE_SHIFT), (flags)) > +#define p2m_l2e_from_pfn(pfn, flags) \ > + l2e_from_pfn((pfn) & ((PADDR_MASK & ~(_PAGE_PSE_PAT | 0UL)) \ > + >> PAGE_SHIFT), (flags) | _PAGE_PSE) > +#define p2m_l3e_from_pfn(pfn, flags) \ > + l3e_from_pfn((pfn) & ((PADDR_MASK & ~(_PAGE_PSE_PAT | 0UL)) \ > + >> PAGE_SHIFT), (flags) | _PAGE_PSE) > > /* PTE flags for the various types of p2m entry */ > #define P2M_BASE_FLAGS \ > @@ -243,7 +250,7 @@ p2m_next_level(struct p2m_domain *p2m, v > l1_entry = __map_domain_page(pg); > for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ ) > { > - new_entry = l1e_from_pfn(pfn + (i * L1_PAGETABLE_ENTRIES), > flags); > + new_entry = l1e_from_pfn(pfn | (i * L1_PAGETABLE_ENTRIES), > flags); > p2m_add_iommu_flags(&new_entry, 1, > IOMMUF_readable|IOMMUF_writable); > p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 2); > } > @@ -277,7 +284,7 @@ p2m_next_level(struct p2m_domain *p2m, v > l1_entry = __map_domain_page(pg); > for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ ) > { > - new_entry = l1e_from_pfn(pfn + i, flags); > + new_entry = l1e_from_pfn(pfn | i, flags); > p2m_add_iommu_flags(&new_entry, 0, 0); > p2m->write_p2m_entry(p2m, gfn, l1_entry + i, new_entry, 1); > } > @@ -595,8 +602,8 @@ p2m_pt_set_entry(struct p2m_domain *p2m, > ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server); > ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct); > l3e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) > - ? l3e_from_pfn(mfn_x(mfn), > - p2m_type_to_flags(p2m, p2mt, mfn, 2) | _PAGE_PSE) > + ? p2m_l3e_from_pfn(mfn_x(mfn), > + p2m_type_to_flags(p2m, p2mt, mfn, 2)) > : l3e_empty(); > entry_content.l1 = l3e_content.l3; > > @@ -686,13 +693,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, > > ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server); > ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct); > - if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) ) > - l2e_content = l2e_from_pfn(mfn_x(mfn), > - p2m_type_to_flags(p2m, p2mt, mfn, 1) > | > - _PAGE_PSE); > - else > - l2e_content = l2e_empty(); > - > + l2e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) > + ? p2m_l2e_from_pfn(mfn_x(mfn), > + p2m_type_to_flags(p2m, p2mt, mfn, 1)) > + : l2e_empty(); > entry_content.l1 = l2e_content.l2; > > if ( entry_content.l1 != 0 ) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |