similar to: [PATCH] xen: use iret directly where possible

[ Expand, correct and clarify comments; minor code change. ] Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically

[ Expand, correct and clarify comments; minor code change. ] Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically

Now that x86-64 has directly accessible percpu variables, it can also implement the direct versions of these operations, which operate on a vcpu_info structure directly embedded in the percpu area. In fact, the 64-bit versions are more or less identical, and so can be shared. The only two differences are: 1. xen_restore_fl_direct takes its argument in eax on 32-bit, and rdi on 64-bit.

Jan, any reason why this patch isn't in Linus's tree already, and why it wasn't marked for inclusion in a -stable kernel release? thanks, greg k-h On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote: > This fixes CVE-2013-0228 / XSA-42 > > Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user > in 32bit PV guest can use to crash the

Jan, any reason why this patch isn't in Linus's tree already, and why it wasn't marked for inclusion in a -stable kernel release? thanks, greg k-h On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote: > This fixes CVE-2013-0228 / XSA-42 > > Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user > in 32bit PV guest can use to crash the

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_64_compat.S | 10 ++-------- arch/x86/include/asm/paravirt.h | 5 ----- arch/x86/include/asm/paravirt_types.h | 8 -------- arch/x86/kernel/asm-offsets_64.c | 1 - arch/x86/kernel/paravirt.c | 5 -----

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

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

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

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

I'm implementing a more efficient version of the Xen iret paravirt_op, so that it can use the real iret instruction where possible. I really need to get access to per-cpu variables, so I can set the event mask state in the vcpu_info structure, but unfortunately at the point where INTERRUPT_RETURN is used in entry.S, the usermode %fs has already been restored. How would you feel if we changed

I'm implementing a more efficient version of the Xen iret paravirt_op, so that it can use the real iret instruction where possible. I really need to get access to per-cpu variables, so I can set the event mask state in the vcpu_info structure, but unfortunately at the point where INTERRUPT_RETURN is used in entry.S, the usermode %fs has already been restored. How would you feel if we changed

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

Instead of using six globally visible paravirt ops structures combine them in a single structure, keeping the original structures as sub-structures. This avoids the need to assemble struct paravirt_patch_template at runtime on the stack each time apply_paravirt() is being called (i.e. when loading a module). Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/hyperv/mmu.c

From: David Vrabel <david.vrabel@citrix.com> In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS (-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event /and/ the process has a pending signal then %eip (and %eax) are corrupted when returning to the main process after handling the signal. The application may then crash with SIGSEGV or a SIGILL or it may have subtly

From: Joerg Roedel <jroedel at suse.de> Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the vCPU when it reaches IRET. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/entry/entry_64.S | 48 +++++++++++++++++++++++++++++++++ arch/x86/include/asm/sev-es.h | 27 +++++++++++++++++++ arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/nmi.c