From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Lagerwall Subject: Re: [PATCH v1 1/5] xsplice: Design document. Date: Tue, 6 Oct 2015 13:57:55 +0100 Message-ID: <5613C553.2040707@citrix.com> References: <1442437276-2620-1-git-send-email-konrad.wilk@oracle.com> <1442437276-2620-2-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZjRpS-0000qy-7f for xen-devel@lists.xenproject.org; Tue, 06 Oct 2015 12:58:50 +0000 In-Reply-To: <1442437276-2620-2-git-send-email-konrad.wilk@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 , xen-devel@lists.xenproject.org, msw@amazon.com, aliguori@amazon.com, amesserl@rackspace.com, rick.harris@rackspace.com, paul.voccio@rackspace.com, steven.wilson@rackspace.com, major.hayden@rackspace.com, josh.kearney@rackspace.com, jinsong.liu@alibaba-inc.com, xiantao.zxt@alibaba-inc.com, boris.ostrovsky@oracle.com, daniel.kiper@oracle.com, elena.ufimtseva@oracle.com, 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, jbeulich@suse.com, andrew.cooper3@citrix.com, mpohlack@amazon.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote: > +### xSplice interdependencies > + > +xSplice patches interdependencies are tricky. > + > +There are the ways this can be addressed: > + * A single large patch that subsumes and replaces all previous ones. > + Over the life-time of patching the hypervisor this large patch > + grows to accumulate all the code changes. > + * Hotpatch stack - where an mechanism exists that loads the hotpatches > + in the same order they were built in. We would need an build-id > + of the hypevisor to make sure the hot-patches are build against the > + correct build. > + * Payload containing the old code to check against that. That allows > + the hotpatches to be loaded indepedently (if they don't overlap) - or > + if the old code also containst previously patched code - even if they > + overlap. > + > +The disadvantage of the first large patch is that it can grow over > +time and not provide an bisection mechanism to identify faulty patches. > + > +The hot-patch stack puts stricts requirements on the order of the patches > +being loaded and requires an hypervisor build-id to match against. > + > +The old code allows much more flexibility and an additional guard, > +but is more complex to implement. > + If the single large patch mechanism is used, a new REPLACE action is needed to atomically replace one patch with another to prevent a window where the hypervisor is unpatched. kpatch has a "replace" command for this purpose. This may be useful even for the other mechanisms listed above. From what I can tell: * kSplice uses old code checking (method [3] above), although in practice the userspace tools implement dependency logic to enforce a linear stack of patches. * kPatch and kGraft recommend using the single large patch mechanism although there's nothing preventing two independent patches from being loaded. -- Ross Lagerwall