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: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 27 September 2017 14:31
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map
> guest mfns
> 
> >>> On 27.09.17 at 14:49, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 27 September 2017 13:47
> >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> >> devel@xxxxxxxxxxxxxxxxxxxx
> >> Subject: RE: [PATCH v7 01/12] x86/mm: allow a privileged PV domain to
> map
> >> guest mfns
> >>
> >> >>> On 27.09.17 at 13:18, <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:
> >> >> > -        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.
> >> >
> >> > Looking at this I wonder whether a cleaner solution would be to
> introduce a
> >> > new domid: DOMID_ANY. This meaning of this would be along the same
> >> sort of
> >> > lines as DOMID_XEN or DOMID_IO and would be used in mmu_update
> to
> >> mean 'any
> >> > page over which the caller has privilege'. Does that sound reasonable?
> >>
> >> Not really, no. Even if the caller has privilege over multiple domains,
> >> it should still specify which one it means. Otherwise we may end up
> >> with a page transferring ownership behind its back, and it doing
> >> something to one domain which was meant to be done to another.
> >>
> >
> > Ok, I'll claim the final cmd value then.
> 
> Final? We've got 5 left (for a total of 3 bits) afaict.

Really? Maybe I misread... looks like only 2 bits to me.

  Paul

> 
> Jan


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