Re: [Xen-devel] [PATCH v8 1/8] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 7 Nov 2018, Jan Beulich wrote:
> >>> On 06.11.18 at 23:42, <sstabellini@xxxxxxxxxx> wrote:
> > On Tue, 9 Oct 2018, Jan Beulich wrote:
> >> >>> On 09.10.18 at 01:37, <sstabellini@xxxxxxxxxx> wrote:
> >> > --- a/xen/include/xsm/dummy.h
> >> > +++ b/xen/include/xsm/dummy.h
> >> > @@ -535,6 +535,20 @@ static XSM_INLINE int 
> >> > xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
> >> >      return xsm_default_action(action, d, t);
> >> >  }
> >> >  
> >> > +/*
> >> > + * Be aware that this is not an exact default equivalence of its flask
> >> > + * variant which also checks if @d and @t "are allowed to share memory
> >> > + * pages", for now, we don't have a proper default equivalence of such a
> >> > + * check.
> >> > + */
> >> > +static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain 
> >> > *d,
> >> > +                                         struct domain *t)
> >> > +{
> >> > +    XSM_ASSERT_ACTION(XSM_TARGET);
> >> > +    return xsm_default_action(XSM_TARGET, current->domain, d) ?:
> >> > +           xsm_default_action(action, current->domain, t);
> >> > +}
> >> 
> >> Does this (specifically xsm/dummy.c)) build with XSM enabled?
> >> Afaict "action" is going to be an undefined symbol in that case.
> > 
> > I tried it and it does build OK
> 
> Oh, I see - that because of the way XSM_ASSERT_ACTION() is
> defined in that case. It's in fact the other way around: For
> consistency with other code, you shouldn't use literal
> XSM_TARGET in the first function invocation.

OK, I'll use "action" in both invocations

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel