similar to: [PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality

On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of two '%' characters instead of one when specifying > a register name. >

On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of two '%' characters instead of one when specifying > a register name. >

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote: > On 17/11/17 19:07, Borislav Petkov wrote: > > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > >> Convert the hard-coded native patch assembly code strings to macros to > >> facilitate sharing common code between 32-bit and 64-bit. > >> > >> These macros will also be used

On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote: > On 17/11/17 19:07, Borislav Petkov wrote: > > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote: > >> Convert the hard-coded native patch assembly code strings to macros to > >> facilitate sharing common code between 32-bit and 64-bit. > >> > >> These macros will also be used

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

Hi folks, With this series, the bulk of the work of pvops64 is done. Here, I integrate most of the paravirt.c and paravirt.h files, making them applicable to both architectures. CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page table integration (patches currently being worked on by Jeremy). Enjoy

Hi folks, With this series, the bulk of the work of pvops64 is done. Here, I integrate most of the paravirt.c and paravirt.h files, making them applicable to both architectures. CONFIG_PARAVIRT is _not_ present yet. Basically, this code is missing page table integration (patches currently being worked on by Jeremy). Enjoy

Convert the hard-coded native patch assembly code strings to macros to facilitate sharing common code between 32-bit and 64-bit. These macros will also be used by a future patch which requires the GCC extended asm syntax of two '%' characters instead of one when specifying a register name. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> ---

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Paravirtualized spinlocks produce some overhead even if the kernel is running on bare metal. The main reason are the more complex locking and unlocking functions. Especially unlocking is no longer just one instruction but so complex that it is no longer inlined. This patch series addresses this issue by adding two more pvops functions to reduce the size of the inlined spinlock functions. When

Paravirtualized spinlocks produce some overhead even if the kernel is running on bare metal. The main reason are the more complex locking and unlocking functions. Especially unlocking is no longer just one instruction but so complex that it is no longer inlined. This patch series addresses this issue by adding two more pvops functions to reduce the size of the inlined spinlock functions. When

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,

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a

On 04/10/17 17:58, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of two '%' characters instead of one when specifying > a register name. > > Signed-off-by:

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