On 01/16/2015 11:06 AM, Jan Beulich wrote:
On 16.01.15 at 16:56, <boris.ostrov...@oracle.com> wrote:
On 01/07/2015 04:12 AM, Jan Beulich wrote:
On 06.01.15 at 14:41, <andrew.coop...@citrix.com> 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
processor.
There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient
Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the
fact
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.
Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
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
hwloc)
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
hypercall?
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?
What is the problem with preempting while in platform op? We already do
this for microcode updates.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
