From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFC v2] xSplice design Date: Fri, 12 Jun 2015 17:17:13 +0100 Message-ID: <557B0609.2070600@citrix.com> References: <20150515194440.GA24313@l.oracle.com> <557AC4D9.2000802@amazon.com> <20150612140328.GG15651@l.oracle.com> <557AED30.4070703@amazon.com> <20150612160924.GC20667@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z3Rng-0000fF-Al for xen-devel@lists.xenproject.org; Fri, 12 Jun 2015 16:27:24 +0000 In-Reply-To: <20150612160924.GC20667@l.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Martin Pohlack Cc: Elena Ufimtseva , jeremy@goop.org, hanweidong@huawei.com, jbeulich@suse.com, john.liuqiming@huawei.com, Paul Voccio , xen-devel@lists.xenproject.org, Daniel Kiper , Major Hayden , liuyingdong@huawei.com, aliguori@amazon.com, konrad@darnok.org, lars.kurth@citrix.com, Steven Wilson , peter.huangpeng@huawei.com, msw@amazon.com, xiantao.zxt@alibaba-inc.com, Rick Harris , boris.ostrovsky@oracle.com, Josh Kearney , jinsong.liu@alibaba-inc.com, Antony Messerli , fanhenglong@huawei.com List-Id: xen-devel@lists.xenproject.org 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