Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Juergen Gross <jgross@xxxxxxxx>]

On 15/04/16 12:20, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 3/3] xen: Document 
> XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result"):
>> On Thu, 2016-04-14 at 18:56 +0100, Ian Jackson wrote:
>>> is very unfortunate.  How is a toolstack to know what to do ?
>>>
>> Yeah, I agree, but again, I think in this case it's possible for
>> toolstack to tell.
> 
> Thanks to both you and Juergen for the explanations.  I'm glad to see
> that things weren't as bad as I feared - I admit that I didn't spend
> the time to completely follow what all the relevant bits of code did.
> 
> Would either of you care to provide a version of my documentation patch
> which answers the questions that my text answers ?  Or shall we commit
> my version and you can edit it in-tree :-).

I can provide an updated patch.

>>         ret = -EPERM;
>>         if ( !is_hardware_domain(current->domain) )
>>             break;
>>
>> which I think satisfies Ian's (legitimate) concern?
> 
> That addresses the security concern, yes.  (Is a driver domain a
> `hardware domain' in this sense?)

The hardware domain is the one domain having direct access to the
native hardware. This is dom0 in most cases. There can be only one
hardware domain.

> All I need now is a recipe for the tools to tell what has happened and
> then I can make xl or libxl at least print comprehensible and correct
> error messages...

So this boils down to finding an appropriate ESOMETHING replacement
for the EBUSY case introduced by the temporary pinning.

I think ENOTEMPTY or EADDRINUSE would fit best.

The EBUSY returns of not successful repair attempts (trying to assign a
cpu to another cpupool) should be changed to e.g. EADDRNOTAVAIL?


Juergen

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