[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 7/8] x86/mm: handle foreign mappings in p2m_entry_modify
> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne <roger.pau@xxxxxxxxxx> wrote: > > So that the specific handling can be removed from > atomic_write_ept_entry and be shared with npt and shadow code. > > This commit also removes the check that prevent non-ept PVH dom0 from > mapping foreign pages. > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Mostly looks good; just a few comments... > > diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h > index f4ec2becbd..1687b31571 100644 > --- a/xen/include/asm-x86/p2m.h > +++ b/xen/include/asm-x86/p2m.h > @@ -932,11 +932,14 @@ int p2m_set_ioreq_server(struct domain *d, unsigned int > flags, > struct hvm_ioreq_server *p2m_get_ioreq_server(struct domain *d, > unsigned int *flags); > > -static inline void p2m_entry_modify(struct p2m_domain *p2m, p2m_type_t nt, > - p2m_type_t ot, unsigned int level) > +static inline int p2m_entry_modify(struct p2m_domain *p2m, p2m_type_t nt, > + p2m_type_t ot, mfn_t nfn, mfn_t ofn, > + unsigned int level) > { > - if ( level != 1 || nt == ot ) > - return; > + BUG_ON(level > 1 && (nt == p2m_ioreq_server || nt == p2m_map_foreign)); > + > + if ( level != 1 || (nt == ot && mfn_eq(nfn, ofn)) ) > + return 0; > > switch ( nt ) > { > @@ -948,6 +951,14 @@ static inline void p2m_entry_modify(struct p2m_domain > *p2m, p2m_type_t nt, > p2m->ioreq.entry_count++; > break; > > + case p2m_map_foreign: > + BUG_ON(!mfn_valid(nfn)); Since we’re going to be returning errors anyway, why not retain the original functionality of returning -EINVAL in this case, rather than BUG_ON? > + > + if ( !page_get_owner_and_reference(mfn_to_page(nfn)) ) > + return -EBUSY; > + > + break; > + > default: > break; > } > @@ -959,9 +970,16 @@ static inline void p2m_entry_modify(struct p2m_domain > *p2m, p2m_type_t nt, > p2m->ioreq.entry_count--; > break; > > + case p2m_map_foreign: > + BUG_ON(!mfn_valid(ofn)); If somehow this happened, then the bug isn’t here but somewhere else; continuing on won’t make things any worse than they would be if this page weren’t removed. I think this should probably be an ASSERT() (to help narrow down where a bug may have come from), followed by a simple return. Likely the worst that would happen here is an un-killable domain; no need to crash production servers in this case. Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |