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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.15 at 17:34, <boris.ostrovsky@xxxxxxxxxx> wrote:
> 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.

While I'm not particularly happy about such, having an explicitly
clobbered field in the interface structure is certainly an option.

> 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.

We have cmd, of which we could use the upper bits just like we do
elsewhere.

Jan


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