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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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.

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.

> 
> ~Andrew

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