All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: [PATCH v4 01/12] x86/mm: allow a privileged PV domain to map guest mfns
Date: Thu, 7 Sep 2017 12:09:04 +0100	[thread overview]
Message-ID: <20170907110904.6qiujaspp4whauqp@citrix.com> (raw)
In-Reply-To: <1c8c071f995346a5afd2d3348ff92e0f@AMSPEX02CL03.citrite.net>

On Thu, Sep 07, 2017 at 12:05:08PM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: 07 September 2017 12:02
> > To: Paul Durrant <Paul.Durrant@citrix.com>
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> > <Andrew.Cooper3@citrix.com>; Jan Beulich <jbeulich@suse.com>; Wei Liu
> > <wei.liu2@citrix.com>
> > 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@citrix.com>
> > > ---
> > > Cc: Jan Beulich <jbeulich@suse.com>
> > > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > > ---
> > >  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!

Oh, yes, I'm utterly confused.  Sorry. :-/

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

  reply	other threads:[~2017-09-07 11:09 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05 11:37 [PATCH v4 00/12] x86: guest resource mapping Paul Durrant
2017-09-05 11:37 ` [PATCH v4 01/12] x86/mm: allow a privileged PV domain to map guest mfns Paul Durrant
2017-09-07 11:02   ` Wei Liu
2017-09-07 11:05     ` Paul Durrant
2017-09-07 11:09       ` Wei Liu [this message]
2017-09-07 11:19     ` Andrew Cooper
2017-09-05 11:37 ` [PATCH v4 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources Paul Durrant
2017-09-07 11:10   ` Wei Liu
2017-09-07 11:18     ` Paul Durrant
2017-09-07 11:36       ` Wei Liu
2017-09-07 11:37         ` Paul Durrant
2017-09-07 11:54         ` Jan Beulich
2017-09-05 11:37 ` [PATCH v4 03/12] tools/libxenforeignmemory: add support for resource mapping Paul Durrant
2017-09-07 11:48   ` Wei Liu
2017-09-05 11:37 ` [PATCH v4 04/12] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint Paul Durrant
2017-09-07 11:48   ` Wei Liu
2017-09-05 11:37 ` [PATCH v4 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table Paul Durrant
2017-09-07 11:49   ` Wei Liu
2017-09-05 11:37 ` [PATCH v4 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn Paul Durrant
2017-09-05 11:37 ` [PATCH v4 07/12] x86/hvm/ioreq: use bool rather than bool_t Paul Durrant
2017-09-07 11:10   ` Wei Liu
2017-09-05 11:37 ` [PATCH v4 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list Paul Durrant
2017-09-07 11:40   ` Wei Liu
2017-09-07 14:41   ` Roger Pau Monné
2017-09-07 14:51     ` Juergen Gross
2017-09-07 14:57       ` Roger Pau Monné
2017-09-07 15:16       ` Jan Beulich
2017-09-08  8:32         ` Paul Durrant
2017-09-05 11:37 ` [PATCH v4 09/12] x86/hvm/ioreq: simplify code and use consistent naming Paul Durrant
2017-09-07 11:45   ` Wei Liu
2017-09-05 11:37 ` [PATCH v4 10/12] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page Paul Durrant
2017-09-07 11:45   ` Wei Liu
2017-09-05 11:37 ` [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted Paul Durrant
2017-09-07 12:00   ` Wei Liu
2017-09-07 12:03     ` Paul Durrant
2017-09-07 12:16       ` Wei Liu
2017-09-07 12:29         ` Paul Durrant
2017-09-07 14:22           ` Wei Liu
2017-09-08  8:34             ` Paul Durrant
2017-09-05 11:37 ` [PATCH v4 12/12] x86/hvm/ioreq: add a new mappable resource type Paul Durrant
2017-09-07 14:51   ` Wei Liu
2017-09-08  8:28     ` Paul Durrant
2017-09-07 14:56   ` Roger Pau Monné
2017-09-07 14:59     ` Wei Liu
2017-09-07 15:23       ` Roger Pau Monné
2017-09-08  8:29         ` Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170907110904.6qiujaspp4whauqp@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.