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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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
> > > > > > > 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@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
> > > > > > 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?
> 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.
-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel