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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Jan
> Beulich
> Sent: 25 September 2017 15:50
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV
> domain to map guest mfns
> 
> >>> On 25.09.17 at 16:42, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 25 September 2017 14:03
> >> >>> On 18.09.17 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
> >> The other aspect I don't understand is why this is needed for PV
> >> Dom0, but not for PVH. The answer here can't be "because PVH
> >> Dom0 isn't supported yet", because it eventually will be, and then
> >> there will still be the problem of PVH supposedly having no notion
> >> of MFNs (be their own or foreign guest ones). The answer also
> >> can't be "since it would use XENMAPSPACE_gmfn_foreign", as
> >> that's acting in terms of GFN too.
> >
> > The hypercall is PV-only. For a PVH/HVM tools domain things are handled
> by
> > doing an add-to-physmap to gfns specified by the tools domain. I have
> tested
> > both PV and HVM clients of my new memory op.
> 
> And how is this add-to-physmap any better superpage shattering
> wise than the old mechansim?

Because the calling domain can make an intelligent choice about what gfns to 
use?

> 
> >> > -        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,
> >>
> >> I'm concerned of the effect of the change on the code paths
> >> which you're not really interested in: alloc_l1_table(),
> >> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
> >> explicitly pass both domains identical, and are now suddenly able
> >> to do things they weren't supposed to do. A similar concern
> >> applies to __do_update_va_mapping() calling mod_l1_table().
> >>
> >> I therefore wonder whether the solution to your problem
> >> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
> >> to improvement suggestions). This at the same time would
> >> address my concern regarding the misleading DOMID_SELF
> >> passing when really a foreign domain's page is meant.
> >
> > Ok. I'm not familiar with MMU_FOREIGN_PT_UPDATE so I'd need to
> investigate.
> > I just need a mechanism for a privileged PV guest to map pages belonging
> to
> > another guest that don't appear in that guests P2M. As I said above, it's
> > much simpler if the tools domain is PVH or HVM.
> 
> Hmm, looks like I wasn't able to express things such that it
> becomes clear the MMU_FOREIGN_PT_UPDATE is the proposed
> (sub-optimal) name for a new sub-op.
> 

Ok. I see what you mean now.

  Paul

> Jan
> 
> 
> _______________________________________________
> 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