[Xen-devel] Returning errno values inside of hypercall structs (was: Re: [PATCH for-4.7 3/4] tools/xsplice: fix mixing system)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.04.16 at 18:16, <roger.pau@xxxxxxxxxx> wrote:
> On Fri, Apr 29, 2016 at 04:30:16PM +0100, Wei Liu wrote:
>> On Fri, Apr 29, 2016 at 05:12:51PM +0200, Roger Pau Monne wrote:
>> > On Fri, Apr 29, 2016 at 04:02:33PM +0100, Wei Liu wrote:
>> > > I have a gut feeling that returning XEN_ errno to userspace program is
>> > > layering violation. They should always be translated to OS level errno
>> > > by privcmd driver.
>> > 
>> > Yes, the error value returned from the hypercall executed is indeed 
>> > translated into the native OS error space. The problem here is that those 
>> > error codes are returned _inside_ of the specific hypercall struct, which 
>> > sadly privcmd doesn't know anything about.
>> > 
>> > And of course teaching privcmd about every possible hypercall struct is 
>> > simply impossible, since some of them are not stable (eg: domctls)
>> >  
>> > > Aren't FreeBSD and NetBSD already doing that?
>> > 
>> > As said above, this is only done for direct return codes, everything 
>> > inside 
> 
>> > of the struct passed to the hypercall is returned as-is.
>> > 
>> > This is a complete mess, and TBH, I don't have a clever idea about how to 
>> > solve it.
>> > 
>> 
>> Me neither. Maybe a new thread should be started to discuss this.
> 
> So here we are.
> 
> In order to put everyone into context: the issue here is that some 
> hypercalls (those that batch several operations) return an array of error 
> codes inside of the hypercall structure. This array of error codes is not 
> standardized, so the privcmd driver doesn't know anything about it, and thus 
> cannot translate it into the native OS error space.

I don't see why these would need translation: Anything in a structure
field simply is in XEN_E* space, and the caller can be easily aware.

> It has also been suggested that the privcmd driver simply doesn't translate 
> error codes at all, and then let the applications figure out if the error 
> code comes from Xen or from the OS. IMHO, this is impossible to achieve, 
> because the ioctl syscall can return an error code that's been forwarded 
> by Xen or a native one, and the application has no way of knowing where is 
> it coming from.

But that's a separate issue from that of passing such values in
structure fields.

Jan


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