| Message ID | 20170822145107.6877-3-paul.durrant@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Aug 22, 2017 at 03:50:56PM +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. > What would be the callchain like in this case? I don't quite understand how this fits with the resource mapping code in this series. > 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 0abb1e284f..aaa9ff5197 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -989,12 +989,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) || > xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) ) > { > gdprintk(XENLOG_WARNING, > -- > 2.11.0 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
> -----Original Message----- > From: Wei Liu [mailto:wei.liu2@citrix.com] > Sent: 24 August 2017 17:33 > 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 v2 REPOST 02/12] x86/mm: allow a > privileged PV domain to map guest mfns > > On Tue, Aug 22, 2017 at 03:50:56PM +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. > > > > What would be the callchain like in this case? It's exactly like foreign mapping but passing DOMID_SELF. I.e. in privcmd (in a PV domain) you have an mfn in your hand that already belongs to you rather than the gmfn of a foreign domain. > > I don't quite understand how this fits with the resource mapping code > in this series. > Because (for a PV caller) mapping a resource gives you back mfns that are assigned to the calling domain, and the most convenient way of using them is to use the existing code that normally deals with priv mapping from a foreign domain, but just allow it to use DOMID_SELF. This patch is all that's required to make that work. Paul > > 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 0abb1e284f..aaa9ff5197 100644 > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -989,12 +989,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) || > > xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) ) > > { > > gdprintk(XENLOG_WARNING, > > -- > > 2.11.0 > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > https://lists.xen.org/xen-devel
On Fri, Aug 25, 2017 at 11:05:54AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Wei Liu [mailto:wei.liu2@citrix.com] > > Sent: 24 August 2017 17:33 > > 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 v2 REPOST 02/12] x86/mm: allow a > > privileged PV domain to map guest mfns > > > > On Tue, Aug 22, 2017 at 03:50:56PM +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. > > > > > > > What would be the callchain like in this case? > > It's exactly like foreign mapping but passing DOMID_SELF. I.e. in > privcmd (in a PV domain) you have an mfn in your hand that already > belongs to you rather than the gmfn of a foreign domain. > > > > > I don't quite understand how this fits with the resource mapping > > code in this series. > > > > Because (for a PV caller) mapping a resource gives you back mfns that > are assigned to the calling domain, and the most convenient way of > using them is to use the existing code that normally deals with priv > mapping from a foreign domain, but just allow it to use DOMID_SELF. > This patch is all that's required to make that work. > So the use case is as followed for PV guests: 1. A guest calls acquire_resource to obtain a list of mfns 2. The guest calls the foreign map API to map those mfns into its own address space via HYPERVISOR_mmu_update The mfns belong to the guest itself. In get_page_from_l1e, l1e contains a valid mfn, real_pg_owner is the real owner of the page, pg_owner is the nominally owner of the page. Shouldn't they be the same domain? I'm still quite baffled how you manage to hit that place.
> -----Original Message----- > From: Wei Liu [mailto:wei.liu2@citrix.com] > Sent: 28 August 2017 15:38 > To: Paul Durrant <Paul.Durrant@citrix.com> > Cc: Wei Liu <wei.liu2@citrix.com>; xen-devel@lists.xenproject.org; Andrew > Cooper <Andrew.Cooper3@citrix.com>; Jan Beulich <jbeulich@suse.com> > Subject: Re: [Xen-devel] [PATCH v2 REPOST 02/12] x86/mm: allow a > privileged PV domain to map guest mfns > > On Fri, Aug 25, 2017 at 11:05:54AM +0100, Paul Durrant wrote: > > > -----Original Message----- > > > From: Wei Liu [mailto:wei.liu2@citrix.com] > > > Sent: 24 August 2017 17:33 > > > 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 v2 REPOST 02/12] x86/mm: allow a > > > privileged PV domain to map guest mfns > > > > > > On Tue, Aug 22, 2017 at 03:50:56PM +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. > > > > > > > > > > What would be the callchain like in this case? > > > > > It's exactly like foreign mapping but passing DOMID_SELF. I.e. in > > privcmd (in a PV domain) you have an mfn in your hand that already > > belongs to you rather than the gmfn of a foreign domain. > > > > > > > > I don't quite understand how this fits with the resource mapping > > > code in this series. > > > > > > > Because (for a PV caller) mapping a resource gives you back mfns that > > are assigned to the calling domain, and the most convenient way of > > using them is to use the existing code that normally deals with priv > > mapping from a foreign domain, but just allow it to use DOMID_SELF. > > This patch is all that's required to make that work. > > > > So the use case is as followed for PV guests: > > 1. A guest calls acquire_resource to obtain a list of mfns > 2. The guest calls the foreign map API to map those mfns into its own > address space via HYPERVISOR_mmu_update > > The mfns belong to the guest itself. > > In get_page_from_l1e, l1e contains a valid mfn, real_pg_owner is the > real owner of the page, pg_owner is the nominally owner of the page. > Shouldn't they be the same domain? I'm still quite baffled how you > manage to hit that place. The issue I hit was l1e_owner and pg_owner being dom0, but real_pg_owner was the guest. Obviously dom0 has privilege to map anything, but it was being denied because pg_owner == l1e_owner. Paul
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 0abb1e284f..aaa9ff5197 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -989,12 +989,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) || xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) ) { gdprintk(XENLOG_WARNING,
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(-)