[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


+ * 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.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.