Re: [Xen-devel] [PATCH v3 09/14] xen: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.11.13 at 10:54, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> On lun, 2013-11-25 at 09:32 +0000, Jan Beulich wrote:
>> >>> On 22.11.13 at 19:55, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
>> > Therefore, I kept this interface as it was here, also considering that:
>> >  - it's pretty late to re-re-redesign;
>> >  - neither this nor the xc one are stable interfaces, so we can come
>> >    back and revisit this later, if we want to.
>> > 
>> > Do you think this could be acceptable?
>> 
>> I wouldn't veto it, but I also dislike reduced flexibility when more
>> flexibility is obviously achievable without much effort.
>> 
> Ok, understood. Ok, I'm up for changing this then. So, let m ask a few
> questions, just to make sure ot get it right this time! ;-P
> 
> You are saying the interface should look as follows:
> 
>  int xc_vcpu_setaffinity(xc_interface *xch,
>                          uint32_t domid,
>                          int vcpu,
>                          xc_cpumap_t cpumap_soft,
>                          xc_cpumap_t cpumap_hard,
>                          uint32_t flags);
> 
> Where both cpumap_soft and cpumap_hard are IN/OUT parameters and, as far
> as OUT is concerned:
>  - cpumap_hard will contain hard-affinity&online
>  - cpumap_soft will contain what?
>   (a) soft-affinity?
>   (b) soft-affinity&online
>   (c) soft-affinity&hard-affinity&online?

(c) seems the best fit - after all it should represent what the
hypervisor will effectively use.

> I would make it (c), as (a) is what xc_vcpu_setaffinity() retrieves,
> while the '&online' part is particularly hard to get from other existing
> calls (either at libxc and libxl level). Among (b) and (c), (c) is what
> would be most useful for an high level caller (like libxl) to have it
> ready, but it's also true that, if I give (b) to it, it could in theory
> reconstruct (c) by himself (with the vice-versa not being true).
> 
> Thoughts?
> 
> Also, should I return something in either *only* of the maps when the
> corresponding flag is set (and of course fill both when both flags are)?

Of course - the other handle may validly be containing garbage in
that case afaict.

Jan


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