similar to: Re: [PATCH, fixed] linux/x86: use sysenter/syscall for 32-bit apps on 64-bit Xen

.. for both 32-bit apps in 64-bit pv guests and 32on64. This patch depends on more than just guest_context saved/restored as guest state during save/restore/migrate (namely the new fields holding callback addresses). Since the 32-bit kernel doesn''t make use of syscall (it would be possible to do so now, when running on a 64-bit hv), the compat mode guest code path for syscall

I implemented sysenter for 32-on-64, since it seemed straightforward enough. It mostly works, but every now and again I get vcpus just hanging in blocked state, as if events are being lost or ignored. Its very similar to the symptoms that other people have reported against the pvops kernel, which I have not managed to reproduce. Perhaps using sysenter is exacerbating an existing bug...

This was set to zero immediately before the #GP injection code, since SYSENTER doesn''t really have a return address. Reported-by: Ian Campbell <Ian.Campbell@citrix.com> Furthermore, UREGS_cs and UREGS_rip don''t need to be written a second time, as the PUSHes above already can/do take care of putting in place the intended values. Signed-off-by: Jan Beulich

In compat mode, the return value here was uninitialized. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1fda49a076ed arch/i386/kernel/sysenter.c --- a/arch/i386/kernel/sysenter.c Fri Apr 06 14:25:09 2007 -0700 +++ b/arch/i386/kernel/sysenter.c Fri Apr 06 14:27:31 2007 -0700 @@ -254,7 +254,7 @@ int arch_setup_additional_pages(struct l { struct mm_struct *mm = current->mm;

In compat mode, the return value here was uninitialized. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 1fda49a076ed arch/i386/kernel/sysenter.c --- a/arch/i386/kernel/sysenter.c Fri Apr 06 14:25:09 2007 -0700 +++ b/arch/i386/kernel/sysenter.c Fri Apr 06 14:27:31 2007 -0700 @@ -254,7 +254,7 @@ int arch_setup_additional_pages(struct l { struct mm_struct *mm = current->mm;

The SYSENTER instruction jumps to a pre-programmed address at privilege level 0. We must not allow execution of guest code at that privilege level, so disable sysenter when we enter the guest (and re-enable it on return). This fixes current case where guest userspace can crash host. This save/restore adds 3% to guest context switch times. (If only there were some kind of scheduler hook or

The SYSENTER instruction jumps to a pre-programmed address at privilege level 0. We must not allow execution of guest code at that privilege level, so disable sysenter when we enter the guest (and re-enable it on return). This fixes current case where guest userspace can crash host. This save/restore adds 3% to guest context switch times. (If only there were some kind of scheduler hook or

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2013-1917 / XSA-44 version 2 Xen PV DoS vulnerability with SYSENTER UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The SYSENTER instruction can be used by PV guests to accelerate system call processing. This

On Wed, Nov 18, 2015 at 12:50 PM, Brian Gerst <brgerst at gmail.com> wrote: > On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski <luto at amacapital.net> wrote: >> 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 >>>

On 11/19/2015 04:55 PM, Boris Ostrovsky 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 calling xen_iret from xen_sysexit we don't

On 11/19/2015 04:55 PM, Boris Ostrovsky 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 calling xen_iret from xen_sysexit we don't

On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski <luto at amacapital.net> wrote: > 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

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

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

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

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

This adds support for CONFIG_COMPAT_VDSO. As this will certainly raise questions, I left in the code needed for an alternative approach (which requires mode C code, but less build script changes). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-02-27/arch/i386/Kconfig =================================================================== ---

Hi, I''m trying to use the SYSCALL/SYSRET opcodes with a minios kernel without much success. Going by the manuals (and linux sources) I first have to setup the STAR and LSTAR registers to define the segment and instruction pointer to be used for SYSCALL: /* * LSTAR and STAR live in a bit strange symbiosis. * They both write to the same internal register. STAR allows

The ALTERNATIVE() and ALTERNATIVE_2() macros are GNU assembler macros, which makes them quite inflexible for future changes. Convert them to preprocessor macros. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/entry/entry_32.S | 12 +++--- arch/x86/entry/entry_64.S | 10 ++--- arch/x86/entry/entry_64_compat.S | 8 ++--