[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] xSplice design
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |