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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.


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.

Ian.

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