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

[Ian Campbell <Ian.Campbell@citrix.com>]

On Fri, 2015-01-16 at 16:06 +0000, Jan Beulich wrote:
> >>> On 16.01.15 at 16:56, <boris.ostrovsky@oracle.com> wrote:
> > On 01/07/2015 04:12 AM, Jan Beulich wrote:
> >>>>> On 06.01.15 at 14:41, <andrew.cooper3@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.ostrovsky@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...

Unlike sysctls, physdevop-s are exposed to/stable for dom0 too aren't
they?

Ian.