From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Lagerwall Subject: Re: [RFC v2] xSplice design Date: Tue, 27 Oct 2015 12:05:01 +0000 Message-ID: <562F686D.5010903@citrix.com> References: <20150515194440.GA24313@l.oracle.com> <557AC4D9.2000802@amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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 1Zr2zy-0007KP-9w for xen-devel@lists.xenproject.org; Tue, 27 Oct 2015 12:05:06 +0000 In-Reply-To: <557AC4D9.2000802@amazon.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: Martin Pohlack , Konrad Rzeszutek Wilk , msw@amazon.com, aliguori@amazon.com, Antony Messerli , Rick Harris , Paul Voccio , Steven Wilson , Major Hayden , Josh Kearney , jinsong.liu@alibaba-inc.com, xiantao.zxt@alibaba-inc.com, boris.ostrovsky@oracle.com, Daniel Kiper , Elena Ufimtseva , bob.liu@oracle.com, lars.kurth@citrix.com, hanweidong@huawei.com, peter.huangpeng@huawei.com, fanhenglong@huawei.com, liuyingdong@huawei.com, john.liuqiming@huawei.com, xen-devel@lists.xenproject.org, jbeulich@suse.com, andrew.cooper3@citrix.com, jeremy@goop.org Cc: konrad@darnok.org List-Id: xen-devel@lists.xenproject.org On 06/12/2015 12:39 PM, Martin Pohlack wrote: > On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote: > [...] >> ## Hypercalls >> >> We will employ the sub operations of the system management hypercall (sysctl). >> There are to be four sub-operations: >> >> * upload the payloads. >> * listing of payloads summary uploaded and their state. >> * getting an particular payload summary and its state. >> * command to apply, delete, or revert the payload. >> >> The patching is asynchronous therefore the caller is responsible >> to verify that it has been applied properly by retrieving the summary of it >> and verifying that there are no error codes associated with the payload. >> >> We **MUST** make it asynchronous due to the nature of patching: it requires >> every physical CPU to be lock-step with each other. The patching mechanism >> while an implementation detail, is not an short operation and as such >> the design **MUST** assume it will be an long-running operation. > > I am not convinced yet, that you need an asynchronous approach here. > > The experience from our prototype suggests that hotpatching itself is > not an expensive operation. It can usually be completed well below 1ms > with the most expensive part being getting the hypervisor to a quiet state. > FWIW, my current implementation (which is almost certainly not optimal) tested on a 72 CPU machine takes about 3ms, whether idle or fully loaded. -- Ross Lagerwall