similar to: [RFC PATCH 00/26] Runtime paravirt patching

On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: > A KVM host (or another hypervisor) might advertise paravirtualized > features and optimization hints (ex KVM_HINTS_REALTIME) which might > become stale over the lifetime of the guest. For instance, the > host might go from being undersubscribed to being oversubscribed > (or the other way round) and it would make sense

On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: > A KVM host (or another hypervisor) might advertise paravirtualized > features and optimization hints (ex KVM_HINTS_REALTIME) which might > become stale over the lifetime of the guest. For instance, the > host might go from being undersubscribed to being oversubscribed > (or the other way round) and it would make sense

On 08.04.20 14:08, Peter Zijlstra wrote: > On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote: >> Mechanism: the patching itself is done using stop_machine(). That is >> not ideal -- text_poke_stop_machine() was replaced with INT3+emulation >> via text_poke_bp(), but I'm using this to address two issues: >> 1) emulation in text_poke() can only easily

Hi, all, I have difficulty on setting up lguest. Basic OS info: gcc 4.1.2 glibc: 2.5.1 binutils: 2.17 kernel: 2.6.23-rc1 Following lguest.txt instruction, I build lguest enaled kernel, disable CONFIG_COMPAT_VDSO, the host kernel boot fine, but when booting Qemu image using lguest laucher program, the guest kernel vmlinux panic, attached console.txt is console output, and config.txt is kernel

Hi, all, I have difficulty on setting up lguest. Basic OS info: gcc 4.1.2 glibc: 2.5.1 binutils: 2.17 kernel: 2.6.23-rc1 Following lguest.txt instruction, I build lguest enaled kernel, disable CONFIG_COMPAT_VDSO, the host kernel boot fine, but when booting Qemu image using lguest laucher program, the guest kernel vmlinux panic, attached console.txt is console output, and config.txt is kernel

On Tue, Apr 07, 2020 at 10:03:06PM -0700, Ankur Arora wrote: > +/* > + * preempt_enable_no_resched() so we don't add any preemption points until > + * after the caller has returned. > + */ > +#define preempt_enable_runtime_patch() preempt_enable_no_resched() > +#define preempt_disable_runtime_patch() preempt_disable() NAK, this is probably a stright preemption bug, also,

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined