Re: [PATCHv2 0/2] xen/privcmd: support for paged-out frames

[David Vrabel <david.vrabel@citrix.com>]

On 29/08/12 19:05, Ian Campbell wrote:
> On Wed, 2012-08-29 at 17:56 +0100, David Vrabel wrote:
>> On 29/08/12 17:23, Ian Campbell wrote:
>>> On Wed, 2012-08-29 at 14:15 +0100, David Vrabel wrote:
>>>> This series is a straight forward-port of some functionality from
>>>> classic kernels to support Xen hosts that do paging of guests.
>>>>
>>>> This isn't functionality the XenServer makes use of so I've not tested
>>>> these with paging in use.
>>>>
>>>> Changes since v1:
>>>>
>>>> - Don't change PRIVCMD_MMAPBATCH (except to #define a constant for the
>>>>   error).  It's broken and not really fixable sensibly and libxc will
>>>>   use V2 if it is available.
>>>> - Return -ENOENT if all failures were -ENOENT.
>>>
>>> Is this behaviour a requirement from something?
>>
>> It's the behaviour libxc is expecting.  It doesn't retry unless errno ==
>> ENOENT.
> 
> Surely if that is the case you must return -ENOENT if *any* failure was
> -ENOENT? That seems to be what the linux-2.6.18-xen.hg implementation
> does.

Yes.

libxc will subsequently fail the whole map call is any frame errors
without ENOENT so if someone was to propose a V3 it may be useful to
return a different error code for other errors.

>>> Usually hypercalls of this type return a global error only if something
>>> went wrong with the general mechanics of the hypercall (e.g. faults
>>> reading arguments etc) and leave reporting of the individual failures of
>>> subops to the op specific field, even if all the subops fail in the same
>>> way.
>>
>> I didn't design this interface...
> 
> The interface you described doesn't make any sense...

I don't entirely agree.  There are three types of result: success,
retryable errors, and fatal errors.  It's not nonsensical to return
different error codes for these.

Regardless, it's not what the original implementation does so I'll fix
rework the patch.

David