From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Pohlack Subject: Re: [RFC v2] xSplice design Date: Fri, 12 Jun 2015 20:36:29 +0200 Message-ID: <557B26AD.1060700@amazon.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> <20150612163939.GA25376@l.oracle.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 1Z3Tpg-0004ms-HI for xen-devel@lists.xenproject.org; Fri, 12 Jun 2015 18:37:36 +0000 In-Reply-To: <20150612163939.GA25376@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 , Andrew Cooper 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.2015 18:39, Konrad Rzeszutek Wilk wrote: > 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. Why would you need it? Do you envision any complex blocking operation to happen when loading a module? I can't think of any off the top of my head. > 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. I don't understand how that relates to the async nature of the other interface parts. Is that similar to the readdir syscall where a second invocation would continue from the current seek pointer? Or do you have something like a pread for a subarray of list entries in mind? It might be a bit tricky to reliably deliver atomic snapshots if a potentially larger list to userland. Maybe a version field might be desirable here. Martin