similar to: [PATCH v3 6/9] x86: prevent inline distortion by paravirt ops

This reverts commit 494b5168f2de009eb80f198f668da374295098dd. The in-kernel workarounds will be replaced with GCC's new "asm inline" syntax. Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com> --- arch/x86/include/asm/paravirt_types.h | 56 ++++++++++++++++++----------------- arch/x86/kernel/macros.S | 1 - 2 files changed, 29 insertions(+), 28

Revert the following 9 commits: [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") This was partially reverted because it made good cleanups irrespective of the inlining issue; the error message is still unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should be kept. [2] d5a581d84ae6 ("x86/cpufeature:

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

Revert the following commits: - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd ("x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs") - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2 ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining bugs") - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200. ("x86/extable: Macrofy inline assembly

Make paravirt_types.h more understandable: - Use more consistent and logical naming - Simplify interfaces - Put related macros together - Improve whitespace Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/include/asm/paravirt_types.h | 104 ++++++++++++++++++---------------- 1 file changed, 54 insertions(+), 50 deletions(-) diff --git

On Tue, Jun 19, 2018 at 12:48:51PM -0700, Nadav Amit wrote: > +#define paravirt_alt \ > + "PARAVIRT_CALL type=\"%c[paravirt_typenum]\"" \ > + " clobber=\"%c[paravirt_clobber]\"" \ > + " pv_opptr=\"%c[paravirt_opptr]\"" That wants to be: + " pv_opptr=\"%c[paravirt_opptr]\";" And other than

Some cleanup to make the code easier to read and understand: - Use the common "PV_" prefix - Simplify the PV_SITE macro interface - Improve whitespace Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/include/asm/paravirt-asm.h | 95 +++++++++++++++++++------------------ 1 file changed, 49 insertions(+), 46 deletions(-) diff --git

There is no need any longer to store the clobbers in struct paravirt_patch_site. Remove clobbers from the struct and from the related macros. While at it fix some lines longer than 80 characters. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 33 +++++++++++++++------------------ arch/x86/include/asm/paravirt_types.h | 1 - 2 files changed,

Hi all, Sorry for the delay. This implements binary patching of call sites for interrupt-related paravirt ops, since no-doubt Andi wasn't the only one to believe this approach is slow. The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM. 2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4 CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the difference

Hi all, Sorry for the delay. This implements binary patching of call sites for interrupt-related paravirt ops, since no-doubt Andi wasn't the only one to believe this approach is slow. The benchmarks were done on a UP 3GHz Pentium 4 with 512MB of RAM. 2.6.17-rc4 vs 2.6.17-rc4 with CONFIG_PARAVIRT=y vs 2.6.17-rc4 CONFIG_PARAVIRT=y with patch. Summary: with binary patching, the difference

This series reverts the in-kernel workarounds for inlining issues. The commit description of 77b0bf55bc67 mentioned "We also hope that GCC will eventually get fixed,..." Now, GCC provides a solution. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html explains the new "asm inline" syntax. The performance issue will be eventually solved. [About Code cleanups] I know Nadam

This series reverts the in-kernel workarounds for inlining issues. The commit description of 77b0bf55bc67 mentioned "We also hope that GCC will eventually get fixed,..." Now, GCC provides a solution. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html explains the new "asm inline" syntax. The performance issue will be eventually solved. [About Code cleanups] I know Nadam

if PIE is enabled, switch the paravirt assembly constraints to be compatible. The %c/i constrains generate smaller code so is kept by default. Position Independent Executable (PIE) support will allow to extend the KASLR randomization range below 0xffffffff80000000. Signed-off-by: Thomas Garnier <thgarnie at chromium.org> Acked-by: Juergen Gross <jgross at suse.com> ---

If PIE is enabled, switch the paravirt assembly constraints to be compatible. The %c/i constrains generate smaller code so is kept by default. Position Independent Executable (PIE) support will allow to extend the KASLR randomization range below 0xffffffff80000000. Signed-off-by: Thomas Garnier <thgarnie at chromium.org> Acked-by: Juergen Gross <jgross at suse.com> ---

plain text document attachment (xx-paravirt-core.patch) Paravirt Ops core files. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/paravirt.c =================================================================== --- /dev/null +++ clean-start/arch/x86_64/kernel/paravirt.c @@ -0,0 +1,504 @@ +/*

plain text document attachment (xx-paravirt-core.patch) Paravirt Ops core files. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/paravirt.c =================================================================== --- /dev/null +++ clean-start/arch/x86_64/kernel/paravirt.c @@ -0,0 +1,504 @@ +/*

Replace all the open-coded macros for generating calls with a pair of more general macros (__PVOP_CALL/VCALL), and redefine all the PVOP_V?CALL[0-4] in terms of them. [ Andrew, Andi: this should slot in immediately after "Document asm-i386/paravirt.h" (paravirt_ops-document-asm-i386-paravirth.patch) ] Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Ingo Molnar

Replace all the open-coded macros for generating calls with a pair of more general macros (__PVOP_CALL/VCALL), and redefine all the PVOP_V?CALL[0-4] in terms of them. [ Andrew, Andi: this should slot in immediately after "Document asm-i386/paravirt.h" (paravirt_ops-document-asm-i386-paravirth.patch) ] Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Ingo Molnar

This saves one insn byte per instance, summing up to a savings of over 4k in my (stripped down) configuration. No variant of to be patched in replacement code relies on the one byte larger size. Signed-off-by: Jan Beulich <jbeulich at suse.com> --- arch/x86/include/asm/paravirt_types.h | 6 ++++++ 1 file changed, 6 insertions(+) --- 4.18-rc2/arch/x86/include/asm/paravirt_types.h +++

With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls to pv_irq_ops function pointers, like: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) In non-Xen paravirt environments -- including native, KVM, Hyper-V, and VMware -- the above code gets patched by native_patch() to look like this instead: pushfq pop %rax nopl 0x0(%rax,%rax,1) So in most scenarios,