[Xen-devel] Hotpatch construction and __LINE__ (was: [RFC PATCH v3.1] xSplice design.)

[Martin Pohlack <mpohlack@xxxxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel