[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

However, an upload_patch/apply_patch split in the hypercall ABI might be
a sensible idea.

~Andrew

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.