Lines Matching refs:code
21 * splice - patch in the binary code with new opcodes
23 * payload - telemetries of the old code along with binary blob of the new
40 and be as simple as possible. The compiled code is contiguous in memory with
41 no gaps - so we have no luxury of 'moving' existing code and must either
42 insert a trampoline to the new code to be executed - or only modify in-place
43 the code if there is sufficient space. The placement of new code has to be done
44 by hypervisor and the virtual address for the new code is allocated dynamically.
47 in the new trampoline code. Where the trampoline is added (inside
50 To lessen the amount of code in hypervisor, the consumer of the API
52 to patch. Combinations of modifying in-place code, adding trampoline, etc
72 ## Patching code
75 That is replace the affected code with new code. Unfortunately the x86
79 appear if the replacement code is longer.
92 and we would like to binary patch the hypervisor with it. The original code
107 bytes of code which alters all the offsets inside the function. To alter
108 these offsets and add the extra 21 bytes of code we might not have enough
135 * Allocating memory for the new code to live in,
137 code (computing the new offset, patching the callq with a new callq).
154 existing function to be patched to jump directly to the new code. This
194 * Allocating memory for the new code to live in,
198 providing an BUG_ON to catch errant code.
232 * The new code that will be patched in.
269 The Xen Live Patch core code loads the payload as a standard ELF binary, relocates it
367 structure and the core code inserts a trampoline at `old_addr` to `new_addr`.
371 and the core code copies the data from the undo buffer (private internal copy)
484 failure. The success/failure error code is provided to the postapply hooks
515 before the current payload application. The success/failure error code is
628 against basic checks and if there are any issues the proper return code
932 on what the CPU supports. This is done by providing multiple streams of code
935 expand the code to place a most generic code in place - emit a special
949 checks failing. Safety checks such as not patching code which
952 #### Rendezvous code instead of stop_machine for patching
954 The hypervisor's time rendezvous code runs synchronously across all CPUs
956 code and result in NMI. As such having the patching be done at the tail
957 of rendezvous code should avoid this problem.
959 However the entrance point for that code is `do_softirq ->
966 #### Before entering the guest code.
983 ### Compiling the hypervisor code
1001 patching such code. Hotpatches may need to bring their own small
1066 grows to accumulate all the code changes.
1071 * Payload containing the old code to check against that. That allows
1073 if the old code also containst previously patched code - even if they
1082 The old code allows much more flexibility and an additional guard,
1114 * NOP out the code sequence if `new_size` is zero.
1128 into the generated code for f2.
1130 Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
1142 1. Transform source code patches for hotpatches to be line-neutral for
1144 reformatting of the source code or by introducing artificial
1230 (Note that this has been borrowed from Linux module signature code.).
1252 the code or data.
1257 we are limited to up to 2GB of virtual address to place the new code
1258 from the old code. That should not be a problem since Xen hypervisor has
1292 with proper offset is used for an unconditional branch to the new code.
1299 The new code is placed in the 8M - 10M virtual address space while the
1300 Xen code is in 2M - 4M. That gives us enough space.