Re: [PATCH v2 12/16] libxl: get and set soft affinity

[George Dunlap <george.dunlap@eu.citrix.com>]

On 14/11/13 15:11, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH v2 12/16] libxl: get and set soft affinity"):
>> which basically means making space for a new cpumap in both
>> vcpu_info (for getting soft affinity) and build_info (for setting
>> it), along with providing the get/set functions, and wiring them
>> to the proper xc calls. Interface is as follows:
>>
>>   * libxl_{get,set}_vcpuaffinity() deals with hard affinity, as it
>>     always has happened;
>>   * libxl_get,set}_vcpuaffinity_soft() deals with soft affinity.
> In practice, doesn't this API plus these warnings mean that a
> toolstack which wants to migrate a domain to a new set of vcpus (or,
> worse, a new cpupool) will find it difficult to avoid warnings from
> libxl ?
>
> Because the toolstack will want to change both the hard and soft
> affinities to new maps, perhaps entirely disjoint from the old ones,
> but can only do one at a time.  So the system will definitely go
> through "silly" states.
>
> This would be solved with an API that permitted setting both sets of
> affinities in a single call, even if the underlying libxc and
> hypercalls are separate, because libxl would do the check only on the
> overall final state.
>
> So perhaps we should have a singe function that can change the
> cpupool, hard affinity, and soft affinity, all at once ?

I think this is probably a good idea.  Would it make sense to basically 
have libxl_[gs]et_vcpuaffinity2(), which takes a parameter that can 
specify that the mask is for either hard, soft, or both?

>
> What if the application makes a call to change the cpupool, without
> touching the affinities ?  Should the affinities be reset
> automatically ?

I think whatever happens for hard affinities right now should be carried on.

  -George