Re: [PATCH 4/5] xen/memory: Fix acquire_resource size semantics

[Julien Grall <julien@xxxxxxx>]

Hi Paul,

On 30/07/2020 09:31, Paul Durrant wrote:
> > diff --git a/xen/common/memory.c b/xen/common/memory.c
> > index dc3a7248e3..21edabf9cc 100644
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -1007,6 +1007,26 @@ static long xatp_permission_check(struct domain *d, 
> > unsigned int space)
> >       return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> >   }
> >
> > +/*
> > + * Return 0 on any kind of error.  Caller converts to -EINVAL.
> > + *
> > + * All nonzero values should be repeatable (i.e. derived from some fixed
> > + * proerty of the domain), and describe the full resource (i.e. mapping the
> s/property/property
>
> > + * result of this call will be the entire resource).
> This precludes dynamically adding a resource to a running domain. Do we really 
> want to bake in that restriction?
AFAICT, this restriction is not documented in the ABI. In particular, it 
is written:
"
The size of a resource will never be zero, but a nonzero result doesn't
guarentee that a subsequent mapping request will be successful.  There
are further type/id specific constraints which may change between the
two calls.
"

So I think a domain couldn't rely on this behavior. Although, it might 
be good to clarify in the comment on top of resource_max_frames that 
this an implementation decision and not part of the ABI.
Cheers,

--
Julien Grall