From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Pohlack Subject: Re: [PATCH v1 1/5] xsplice: Design document. Date: Mon, 26 Oct 2015 13:01:36 +0100 Message-ID: <562E1620.30301@amazon.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" 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 1ZqgTl-00037U-W2 for xen-devel@lists.xenproject.org; Mon, 26 Oct 2015 12:02:22 +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, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote: [...] > +### xsplice_patch > + > +This structure has the binary code (or data) to be patched. Depending on the > +type it can either an inline patch (data or text) or require an relocation > +change (which requires a trampoline). Naturally it also points to a blob > +of the binary data to patch in, and the size of the patch. On the Xen developer summit we agreed to start with a minimal approach first. Based on looking at the last ~50 XSA patches, I do think we can do *without* the in-place patching and would propose to tackle this approach later or not at all. [...] > +### Symbol names > + > + > +Xen as it is now, has a couple of non-unique symbol names which will > +make runtime symbol identification hard. Sometimes, static symbols > +simply have the same name in C files, sometimes such symbols get > +included via header files, and some C files are also compiled > +multiple times and linked under different names (guest_walk.c). > + > +As such we need to modify the linker to make sure that the symbol > +table qualifies also symbols by their source file name. > + > +For the awkward situations in which C-files are compiled multiple > +times patches we would need to some modification in the Xen code. > + > + > +The convention for file-type symbols (that would allow to map many > +symbols to their compilation unit) says that only the basename (i.e., > +without directories) is embedded. This creates another layer of > +confusion for duplicate file names in the build tree. > + > +That would have to be resolved. Another approach here would be to qualify symbol names by the object-file name which contains them + a unique path component, for example: drivers/pci/pci.o arch/x86/pci.o arch/x86/x86_64/pci.o > + > +
> +> find . -name \*.c -print0 | xargs -0 -n1 basename | sort | uniq -c | sort -n | tail -n10
> +      3 shutdown.c
> +      3 sysctl.c
> +      3 time.c
> +      3 xenoprof.c
> +      4 gdbstub.c
> +      4 irq.c
> +      5 domain.c
> +      5 mm.c
> +      5 pci.c
> +      5 traps.c
> +
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