From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Pohlack Subject: Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.) Date: Wed, 5 Aug 2015 10:55:42 +0200 Message-ID: <55C1CF8E.5090907@amazon.com> References: <1438024817-26942-1-git-send-email-konrad.wilk@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 1ZMuUs-0004Y7-VQ for xen-devel@lists.xenproject.org; Wed, 05 Aug 2015 08:56:27 +0000 In-Reply-To: <1438024817-26942-1-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, daniel.kiper@oracle.com, elena.ufimtseva@oracle.com, bob.liu@oracle.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, jeremy@goop.org, dslutz@verizon.com, "Doebel, Bjoern" List-Id: xen-devel@lists.xenproject.org Hi, Another high-level point to think about is how we want to handle inlined __LINE__ references. This problem is related to hotpatch construction and potentially has influence on the design of the hotpatching infrastructure in Xen. Let me try to explain the problem: We have file1.c with functions f1 and f2 (in that order). f2 contains a BUG() (or WARN()) macro and at that point embeds the source line number into the generated code for f2. Now we want to hotpatch f1 and the hotpatch source-code patch adds 2 lines to f1 and as a consequence shifts out f2 by two lines. The newly constructed file1.o will now contain differences in both binary functions f1 (because we actually changed it with the applied patch) and f2 (because the contained BUG macro embeds the new line number). Without additional information, an algorithm comparing file1.o before and after hotpatch application will determine both functions to be changed and will have to include both into the binary hotpatch. Options: 1. Transform source code patches for hotpatches to be line-neutral for each chunk. This can be done in almost all cases with either reformatting of the source code or by introducing artificial preprocessor "#line n" directives to adjust for the introduced differences. This approach is low-tech and simple. Potentially generated backtraces and existing debug information refers to the original build and does not reflect hotpatching state except for actually hotpatched functions but should be mostly correct. 2. Ignoring the problem and living with artificially large hotpatches that unnecessarily patch many functions. This approach might lead to some very large hotpatches depending on content of specific source file. It may also trigger pulling in functions into the hotpatch that cannot reasonable be hotpatched due to limitations of a hotpatching framework (init-sections, parts of the hotpatching framework itself, ...) and may thereby prevent us from patching a specific problem. The decision between 1. and 2. can be made on a patch--by-patch basis. 3. Introducing an indirection table for storing line numbers and treating that specially for binary diffing. I believe Linux follows this approach, but the details escape me ATM. We might either use this indirection table for runtime use and patch that with each hotpatch (similarly to exception tables) or we might purely use it when building hotpatches to ignore functions that only differ at exactly the location where a line-number is embedded. Similar considerations are true to a lesser extent for __FILE__, but I would argue that file renaming should be done outside of hotpatches. Martin On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote: > Hey! > > Since v3 [http://lists.xen.org/archives/html/xen-devel/2015-07/msg00990.html] > - Nailed down the comments, ingested them in. > - Wrote and tested some code. > RFC v2 [http://lists.xen.org/archives/html/xen-devel/2015-05/msg02142.html] > - Ingested every review comment in. > > > The patches for the code are a shell - there is no patching done at all and > it is very much just to test out the design and hypercalls. The hard parts > are yet to come :-) > > At the Seattle LinuxCon/Xen Summit I will be presenting about xSplice and > referring to this URL. There is also an slot for brainstorming to talk > in details about things we disagree - and there is ample time to talk > during dinner. Martin who has been heavily reviewing the design will be there > and I hope other folks will be there as well to shape the design and > how we want this to work. > > The big outstanding issues are how we want to handle preemption. That > is the problem of making an hypercall and waiting for the hypervisor > to do its job (and the VCPU is blocked). In the past some XSAs have come > out to resolve this and I would very much like this to have it addressed at start. > > I think the other issues that have been raised should also be discussed > naturally, but the above is crucial (at least for me). I've attached the > patches on how I thought the preemption part could be solved by having an 'worker' > in hypervisor acting on the commands - and we just poll on the status to see > what the hypervisor has done so far. > > Lastly, I also plan to add an Wiki to outline the dependency implementation > parts that so far bubbled up - I figured Wiki would be better as some folks > could put their name behind it. > > Now please excuse the roughness of the patch and this giant one huge having > everything in it. It ought to be split in three at least: hypervisor, toolstacks > (libxc and libxl) - that is to be done later. > > docs/misc/xsplice.h | 80 +++ > docs/misc/xsplice.markdown | 1230 +++++++++++++++++++++++++++++++++++++++++ > docs/misc/xsplice_test.c | 78 +++ > tools/libxc/include/xenctrl.h | 16 + > tools/libxc/xc_misc.c | 183 ++++++ > tools/libxc/xc_private.c | 3 + > tools/misc/Makefile | 4 + > tools/misc/xen-xsplice.c | 385 +++++++++++++ > xen/common/Makefile | 1 + > xen/common/kernel.c | 11 + > xen/common/keyhandler.c | 8 +- > xen/common/sysctl.c | 5 + > xen/common/version.c | 5 + > xen/common/xsplice.c | 405 ++++++++++++++ > xen/include/public/sysctl.h | 66 +++ > xen/include/public/version.h | 4 + > xen/include/xen/compile.h.in | 1 + > xen/include/xen/version.h | 1 + > xen/include/xen/xsplice.h | 9 + > 19 files changed, 2494 insertions(+), 1 deletion(-) > > Konrad Rzeszutek Wilk (2): > xsplice: rfc.v3.1 > xsplice: Add hook for build_id > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B