From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC v2] xSplice design Date: Fri, 12 Jun 2015 12:39:39 -0400 Message-ID: <20150612163939.GA25376@l.oracle.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> <557B0609.2070600@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z3Rzy-00028a-1a for xen-devel@lists.xenproject.org; Fri, 12 Jun 2015 16:40:06 +0000 Content-Disposition: inline In-Reply-To: <557B0609.2070600@citrix.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: Andrew Cooper Cc: Elena Ufimtseva , jeremy@goop.org, hanweidong@huawei.com, jbeulich@suse.com, john.liuqiming@huawei.com, Paul Voccio , Daniel Kiper , Major Hayden , liuyingdong@huawei.com, konrad@darnok.org, aliguori@amazon.com, xiantao.zxt@alibaba-inc.com, lars.kurth@citrix.com, Steven Wilson , peter.huangpeng@huawei.com, msw@amazon.com, xen-devel@lists.xenproject.org, Rick Harris , boris.ostrovsky@oracle.com, Josh Kearney , jinsong.liu@alibaba-inc.com, Antony Messerli , Martin Pohlack , fanhenglong@huawei.com List-Id: xen-devel@lists.xenproject.org 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