>>> On 21.09.16 at 18:57, <konrad.w...@oracle.com> wrote: > The NOP functionality will NOP any of the code at > the 'old_addr' or at 'name' if the 'new_addr' is zero. > The purpose of this is to NOP out calls, such as: > > e8 <4-bytes-offset> > > (5 byte insn), or on ARM a 4 byte insn for branching. > > We need the EIP of where we need to the NOP, and that can > be provided via the `old_addr` or `name`. > > If the `old_addr` is provided we will NOP 'new_size' > amount of bytes at that location. > > The amount is up to 31 instructions if desired (which is > the size of the opaque member). If there is a need to NOP > more then: a) more 'struct livepatch_func' structures need > to be present, b) we have to implement a variable size > buffer (in the future), or c) first byte an unconditional > branch skipping the to be disabled code (of course provided > there are no branch targets in the middle). > > While at it, also unify the code on x86 patching so > it is a bit simpler (instead of two seperate writes > just make it one memcpy). > > And introduce a general livepatch_insn_len inline function > that would depend on platform specific instruction size > (for a unconditional branch). As such we also rename the > PATCH_INSN_SIZE to ARCH_PATCH_INSN_SIZE. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
