[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 01/12] x86/mm: allow a privileged PV domain to map guest mfns



> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: 07 September 2017 12:02
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v4 01/12] x86/mm: allow a privileged PV
> domain to map guest mfns
> 
> On Tue, Sep 05, 2017 at 12:37:05PM +0100, Paul Durrant wrote:
> > In the case where a PV domain is mapping guest resources then it needs
> make
> > the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the
> guest
> > domid, so that the passed in gmfn values are correctly treated as mfns
> > rather than gfns present in the guest p2m.
> >
> > This patch removes a check which currently disallows mapping of a page
> when
> > the owner of the page tables matches the domain passed to
> > HYPERVISOR_mmu_update, but that domain is not the real owner of the
> page.
> > The check was introduced by patch d3c6a215ca9 ("x86: Clean up
> > get_page_from_l1e() to correctly distinguish between owner-of-pte and
> > owner-of-data-page in all cases") but it's not clear why it was needed.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > ---
> > Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > ---
> >  xen/arch/x86/mm.c | 13 ++++++++-----
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > index c94f1e5406..bd8aeac59e 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -1024,12 +1024,15 @@ get_page_from_l1e(
> >                     (real_pg_owner != dom_cow) ) )
> >      {
> >          /*
> > -         * Let privileged domains transfer the right to map their target
> > -         * domain's pages. This is used to allow stub-domain pvfb export to
> > -         * dom0, until pvfb supports granted mappings. At that time this
> > -         * minor hack can go away.
> > +         * If the real page owner is not the domain specified in the
> > +         * hypercall then establish that the specified domain has
> > +         * mapping privilege over the page owner.
> > +         * This is used to allow stub-domain pvfb export to dom0. It is
> > +         * also used to allow a privileged PV domain to map mfns using
> > +         * DOMID_SELF, which is needed for mapping guest resources such
> > +         * grant table frames.
> >           */
> > -        if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
> > +        if ( (real_pg_owner == NULL) ||
> 
> I still can't quite figure out if it is safe to remove the check.
> 
> Looking at the rest of the series, you already have the foreign domid to
> hand when you call the get_resource hypercall. What is wrong with using
> that directly? Why do you need DOMID_SELF in the first place?

Because the page is not in the foreign domain's p2m... that's kind of the 
entire point of the resource mapping API!

  Paul

> 
> >               xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
> >          {
> >              gdprintk(XENLOG_WARNING,
> > --
> > 2.11.0
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > https://lists.xen.org/xen-devel

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.