Re: [Xen-devel] [RFC v2] xSplice design

[Martin Pohlack <mpohlack@xxxxxxxxxx>]

On 12.06.2015 18:39, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 12, 2015 at 05:17:13PM +0100, Andrew Cooper wrote:
>> On 12/06/15 17:09, Konrad Rzeszutek Wilk wrote:
>>>
>>>>> The _GET_STATUS does not enforce this and can take longer giving us
>>>>> more breathing room - and also unbounded time - which means if
>>>>> we were to try to cancel it (say it had run for an hour and still
>>>>> could not patch it)- we have to add some hairy code to
>>>>> deal with cancelling asynchronous code.
>>>>>
>>>>> Your way is simpler - but I would advocate expanding the -EAGAIN to _all_
>>>>> the xSplice hypercalls. Thoughts?
>>>> In my experience, you only need the EAGAIN for hypercalls that use the
>>>> quiet state.  Depending on the design, that would be the operations that
>>>> do hotpatch activation and deactivation (i.e., the actual splicing).
>>> The uploading of the patch could be slow - as in the checking to be done
>>> and on an big patch (2MB or more?) it would be good to try again.
>>
>> If a patch is greater than a few kb, it is probably not something
>> sensible to be patching.
> 
> Potentially. It could be an cumlative update containing mulitple XSAs.
> 
>>
>> However, an upload_patch/apply_patch split in the hypercall ABI might be
>> a sensible idea.
> 
> The design has that (it has four hypercalls actually).
> 
> The question is whether that upload_patch hypercall should also
> have the EAGAIN mechansim baked in the design.

Why would you need it?  Do you envision any complex blocking operation
to happen when loading a module?  I can't think of any off the top of my
head.

> The other one (GET_LIST) has it too - and can return EAGAIN with an
> count of how many there are left so the user-space can pick up.

I don't understand how that relates to the async nature of the other
interface parts.  Is that similar to the readdir syscall where a second
invocation would continue from the current seek pointer?

Or do you have something like a pread for a subarray of list entries in
mind?

It might be a bit tricky to reliably deliver atomic snapshots if a
potentially larger list to userland.  Maybe a version field might be
desirable here.

Martin


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