similar to: [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

Displaying 20 results from an estimated 2000 matches similar to: "[PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit"

2015 Nov 18
8
[PATCH 0/3] Fix and cleanup for 32-bit PV sysexit
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
2015 Nov 18
8
[PATCH 0/3] Fix and cleanup for 32-bit PV sysexit
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
2017 Oct 04
31
[PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
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
2017 Oct 04
31
[PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality
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
2015 Nov 18
4
[PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky <boris.ostrovsky at oracle.com> wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up
2015 Nov 18
4
[PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky <boris.ostrovsky at oracle.com> wrote: > After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c > ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up
2007 Oct 31
3
[PATCH 0/7] (Re-)introducing pvops for x86_64 - Consolidation part
Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of
2007 Oct 31
3
[PATCH 0/7] (Re-)introducing pvops for x86_64 - Consolidation part
Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of
2017 May 19
13
[PATCH 00/10] paravirt: make amount of paravirtualization configurable
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,
2017 May 19
13
[PATCH 00/10] paravirt: make amount of paravirtualization configurable
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,
2007 Oct 15
13
[PATCH 00/12] xen/paravirt_ops patches for 2.6.24
Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -
2007 Oct 15
13
[PATCH 00/12] xen/paravirt_ops patches for 2.6.24
Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -
2007 Oct 15
13
[PATCH 00/12] xen/paravirt_ops patches for 2.6.24
Hi Linus, Here's a set of patches to update paravirt_ops and Xen for 2.6.24 A quick overview of the patchset: paravirt_ops: Remove the monolithic paravirt_ops structure, and replace it with smaller structures of related functions. Also, clean up the handling of lazy mode to make it easier to implement. x86/mm/init.c: remove a chunk of dead code Xen: - remove duplicate includes -
2015 Nov 18
0
[PATCH 2/3] x86: irq_enable_sysexit pv op is no longer needed
Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> --- arch/x86/entry/entry_32.S | 8 ++------ arch/x86/include/asm/paravirt.h | 7 ------- arch/x86/include/asm/paravirt_types.h | 9 --------- arch/x86/kernel/asm-offsets.c | 3 --- arch/x86/kernel/paravirt.c | 7
2020 May 18
0
[PATCH 4.4 67/86] x86/paravirt: Remove the unused irq_enable_sysexit pv op
From: Boris Ostrovsky <boris.ostrovsky at oracle.com> commit 88c15ec90ff16880efab92b519436ee17b198477 upstream. As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests", the irq_enable_sysexit pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky <boris.ostrovsky at
2020 May 18
0
Patch "x86/paravirt: Remove the unused irq_enable_sysexit pv op" has been added to the 4.4-stable tree
This is a note to let you know that I've just added the patch titled x86/paravirt: Remove the unused irq_enable_sysexit pv op to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-paravirt-remove-the-unused-irq_enable_sysexit-pv-op.patch and it can be found in the queue-4.4
2018 Aug 13
11
[PATCH v2 00/11] x86/paravirt: several cleanups
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
2018 Aug 10
13
[PATCH 00/10] x86/paravirt: several cleanups
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
2015 Nov 18
0
[PATCH 1/3] x86/xen: Avoid fast syscall path for Xen PV guests
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_regs). Since we end up calling xen_iret from xen_sysexit we don't need to fix up the stack and instead follow entry_SYSENTER_32's IRET
2014 Oct 27
5
[PATCH v12 09/11] pvqspinlock, x86: Add para-virtualization support
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