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

Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient

On 01/16/2015 11:20 AM, Jan Beulich wrote:
On 16.01.15 at 17:14, <boris.ostrovsky@xxxxxxxxxx> wrote:
On 01/16/2015 11:06 AM, Jan Beulich wrote:
On 16.01.15 at 16:56, <boris.ostrovsky@xxxxxxxxxx> wrote:
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, <andrew.cooper3@xxxxxxxxxx> wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each

There is also no need to copy whole op to user at the end, max_cpu_index is

Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
If we are going to change the hypercall, then can we see about making it
a stable interface (i.e. not a sysctl/domctl)?  There are non-toolstack
components which might want/need access to this information.  (i.e. I am
still looking for a reasonable way to get this information from Xen in
In which case leaving the sysctl alone and just adding a new non-sysctl
interface should be considered.
(Sorry for late reply)

Would a platform op be an option here or do you prefer a whole new
  From an abstract pov a platform op would be fine, but iirc you had
a need for preempting, which doesn't work well for that hypercall.
A whole new one seems overkill too. Perhaps slightly bending what
physdevop-s are used for might be an option...
Since the plan is to query for both CPU and IO topologies physdevops
doesn't seem to be a logical place for that, does it?
That's why I said "slightly bending ..."

What is the problem with preempting while in platform op? We already do
this for microcode updates.
But there we don't need to alter the arguments passed to the
hypercall, whereas you will need a way to encode where to
continue from.

I needed to do this with last version and ended up having a field in the interface structure that hypervisor updates before issuing a continuation.

And I think I'd have to do the same for either platform op or physop since neither has an extra argument for passing via a continuation.


Xen-devel mailing list



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