Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* error codes

[Juergen Gross <jgross@xxxxxxxx>]

On 15/04/16 17:25, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_* 
> error codes"):
>> Requested-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> Thanks this is very helpful.  I think it should go in as soon as the
> actual hypervisor code side has the appropriate ack.
> 
> But I have some suggestions for enhancement:
> 
>> +/*
>> + * Error return values of cpupool operations:
>> + *
>> + * -EADDRINUSE:
>> + *  XEN_SYSCTL_CPUPOOL_OP_RMCPU: A vcpu is temporarily pinned to the cpu
>> + *    which is to be removed from a cpupool.
> 
> I think this ought to mention the anomalous state the pcpu is left in,
> and advise what should be done about it.  I think it would be helpful
> to crib from my earlier xxx-ful text.  How about:
> 
>   In this case RMCPU may have been partially carried out and the pcpu
>   is left in an anomalous state.  In this state the pcpu may be used
>   by some not readily predictable subset of the vcpus (domains) whose
>   vcpus are in the old cpupool.
>  
>> The anomalous situation can be recovered by adding the pcpu back to
>> the cpupool it came from, and then retrying the RMCPU.
> 
> But I notice that the code you propose for libxc doesn't do the
> re-add: it just retries the remove.  So either the text above (which
> you and Dario seemed to agree with) is wrong, or the libxc code is
> wrong.

Re-adding it not necessary. A retry is all that is needed. In case
retries don't succeed for a long time either re-adding the cpu to
it's original pool or doing a "xl vcpu-pin -f ..." and a retry should
clean up the situation.

> And, perhaps we ought to mention here that this temporary pinning can
> only be done by the hardware domain ?  Or at least refer to the
> temporary pin operation.

Yes, together with the vcpu-pin -f hint.

I think this can wait until next week.


Juergen

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