On 04/07/2015 12:04 PM, Andrew Cooper wrote:
On 06/04/15 23:12, Boris Ostrovsky wrote:
A number of changes to XEN_SYSCTL_numainfo interface:
* Make sysctl NUMA topology query use fewer copies by combining some
fields into a single structure and copying distances for each node
in a single copy.
* NULL meminfo and distance handles are a request for maximum number
of nodes (num_nodes). If those handles are valid and num_nodes is
is smaller than the number of nodes in the system then -ENOBUFS is
returned (and correct num_nodes is provided)
* Instead of using max_node_index for passing number of nodes keep this
value in num_nodes: almost all uses of max_node_index required adding
or subtracting one to eventually get to number of nodes anyway.
* Replace INVALID_NUMAINFO_ID with XEN_INVALID_MEM_SZ and add
XEN_INVALID_NODE_DIST.
Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
This subtly changes the behaviour of XEN_SYSCTL_numainfo with regards to
NULL guest handles.
Previously, a caller was able to select which information they wanted by
choosing which guest handles were non-NULL.
With the new semantics, the caller must pass both ni->meminfo and
ni->distance to get either bit of information. Each
copy_to_guest_offset() should be gated on a !guest_handle_is_null() so a
caller can request meminfo information without distance information.
Currently the caller, in fact, can have either of three pointers
(node_to_memsize, node_to_memfree or node_to_node_distance) as NULL and
the hypervisor will fill whichever pointer is valid. Because I put the
first two together into a struct we are already changing behavior in
that regard. Not to mention that having all three as NULL now has new
meaning as well.
I thought that either both pointers should be valid or neither. If
people disagree I can change this.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel