search for: module_fin

...unlock() can be called in many places, including >> loadable kernel modules. Can the paravirt_patch_ident_32() function able to >> patch all of them in reasonable time? How about a kernel module loaded later >> at run time? > modules should be fine, see arch/x86/kernel/module.c:module_finalize() > -> apply_paravirt(). > > Also note that the 'default' text is an indirect call into the paravirt > ops table which routes to the 'right' function, so even if the text > patching would be 'late' calls would 'work' as expected, just slower....

...unlock() can be called in many places, including >> loadable kernel modules. Can the paravirt_patch_ident_32() function able to >> patch all of them in reasonable time? How about a kernel module loaded later >> at run time? > modules should be fine, see arch/x86/kernel/module.c:module_finalize() > -> apply_paravirt(). > > Also note that the 'default' text is an indirect call into the paravirt > ops table which routes to the 'right' function, so even if the text > patching would be 'late' calls would 'work' as expected, just slower....

This is a small series getting rid of paravirt patching by switching completely to alternative patching for the same functionality. The basic idea is to add the capability to switch from indirect to direct calls via a special alternative patching option. This removes _some_ of the paravirt macro maze, but most of it needs to stay due to the need of hiding the call instructions from the compiler

This is a small series getting rid of paravirt patching by switching completely to alternative patching for the same functionality. The basic idea is to add the capability to switch from indirect to direct calls via a special alternative patching option. This removes _some_ of the paravirt macro maze, but most of it needs to stay due to the need of hiding the call instructions from the compiler

...turn; + apply_pv_alternatives(); + if (x86_hyper->init_platform) x86_hyper->init_platform(); } diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c index 62e7d70aadd5..34ec137e302a 100644 --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -213,8 +213,8 @@ int module_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs, struct module *me) { - const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL, - *para = NULL, *orc = NULL, *orc_ip = NULL; + const Elf_Shdr *s, *text = NULL, *alt = NULL, *pv_alt = NULL, + *locks = NULL, *para = NULL, *orc =...

...h/i386/kernel/module.c working-2.6.17-rc4-bench/arch/i386/kernel/module.c --- working-2.6.17-rc4-function-call-abstraction/arch/i386/kernel/module.c 2006-05-16 10:50:48.000000000 +1000 +++ working-2.6.17-rc4-bench/arch/i386/kernel/module.c 2006-05-22 15:21:55.000000000 +1000 @@ -108,7 +108,8 @@ int module_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs, struct module *me) { - const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL; + const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL, + *para = NULL; char *secstrings = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_off...

...h/i386/kernel/module.c working-2.6.17-rc4-bench/arch/i386/kernel/module.c --- working-2.6.17-rc4-function-call-abstraction/arch/i386/kernel/module.c 2006-05-16 10:50:48.000000000 +1000 +++ working-2.6.17-rc4-bench/arch/i386/kernel/module.c 2006-05-22 15:21:55.000000000 +1000 @@ -108,7 +108,8 @@ int module_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs, struct module *me) { - const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL; + const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL, + *para = NULL; char *secstrings = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_off...

...rn is that spin_unlock() can be called in many places, including > loadable kernel modules. Can the paravirt_patch_ident_32() function able to > patch all of them in reasonable time? How about a kernel module loaded later > at run time? modules should be fine, see arch/x86/kernel/module.c:module_finalize() -> apply_paravirt(). Also note that the 'default' text is an indirect call into the paravirt ops table which routes to the 'right' function, so even if the text patching would be 'late' calls would 'work' as expected, just slower.

...ding >>> loadable kernel modules. Can the paravirt_patch_ident_32() function >>> able to >>> patch all of them in reasonable time? How about a kernel module >>> loaded later >>> at run time? >> modules should be fine, see arch/x86/kernel/module.c:module_finalize() >> -> apply_paravirt(). >> >> Also note that the 'default' text is an indirect call into the paravirt >> ops table which routes to the 'right' function, so even if the text >> patching would be 'late' calls would 'work' as exp...

On 10/24/2014 04:54 AM, Peter Zijlstra wrote: > On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote: > >> Since enabling paravirt spinlock will disable unlock function inlining, >> a jump label can be added to the unlock function without adding patch >> sites all over the kernel. > But you don't have to. My patches allowed for the inline to remain, > again

On 10/24/2014 04:54 AM, Peter Zijlstra wrote: > On Thu, Oct 16, 2014 at 02:10:38PM -0400, Waiman Long wrote: > >> Since enabling paravirt spinlock will disable unlock function inlining, >> a jump label can be added to the unlock function without adding patch >> sites all over the kernel. > But you don't have to. My patches allowed for the inline to remain, > again

OK, this is the revised paravirt.h (Andi has seen this before), then the second is the binary patching stuff. More things get added to the paravirt struct in future patches, but this basic stuff hasn't changed for some time. ==== This patch does the dumbest possible replacement of paravirtualized instructions: calls through a "paravirt_ops" structure. Currently these are function

The following patches introduce the core infrastructure needed to paravirtualize the 32-bit x86 Linux kernel. This is done by moving virtualization sensitive insn's or code paths to a function table, paravirt_ops. This structure can be populated with hypervisor specific calls or native stubs and currently support running on bare metal, VMI, Xen, or Lhype. These patches apply to

The following patches introduce the core infrastructure needed to paravirtualize the 32-bit x86 Linux kernel. This is done by moving virtualization sensitive insn's or code paths to a function table, paravirt_ops. This structure can be populated with hypervisor specific calls or native stubs and currently support running on bare metal, VMI, Xen, or Lhype. These patches apply to

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops which depends on the patch series I sent out, ia64/pv_ops, xen: more paravirtualization. The binary patch optimization is important on