qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 09/10] target/i386: implement 32-bit SYSENTER for linux-us


From: Richard Henderson
Subject: Re: [PATCH v2 09/10] target/i386: implement 32-bit SYSENTER for linux-user
Date: Tue, 20 Jun 2023 18:22:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

On 6/20/23 17:16, Paolo Bonzini wrote:
TCG reports the SEP feature (SYSENTER/SYSEXIT) in user mode emulation,
but does not plumb it into the linux-user run loop.  Split the helper into
system emulation and user-mode emulation cases and implement the latter.

SYSENTER does not have the best design for a kernel-mode entry
instruction, and therefore Linux always makes it return to the
vsyscall page.  Because QEMU does not provide the_contents_  of
the vsyscall page, the instructions executed after SYSEXIT have
to be emulated by hand until the first RET.

Some corner cases, such as restarting the system call after the
system call has rewritten the SYSENTER instruction, are not emulated
correctly.  On Linux, the system call restart uses the SYSENTER
call in the vsyscall page, while on QEMU it uses the emulated
program's instruction.

Signed-off-by: Paolo Bonzini<pbonzini@redhat.com>
---
  linux-user/i386/cpu_loop.c          | 51 +++++++++++++++++++++++++++--
  target/i386/cpu.c                   |  9 ++++-
  target/i386/cpu.h                   |  1 +
  target/i386/helper.h                |  2 +-
  target/i386/tcg/seg_helper.c        | 33 -------------------
  target/i386/tcg/sysemu/seg_helper.c | 33 +++++++++++++++++++
  target/i386/tcg/translate.c         |  2 +-
  target/i386/tcg/user/seg_helper.c   | 16 +++++++++
  8 files changed, 109 insertions(+), 38 deletions(-)

I'm not keen on this.

This belongs with the rest of the vdso (see patches posted years ago; committing binary blobs rejected, still waiting on a decent way to invoke cross-compilers to build them).

Further, this shouldn't ever be reachable, because AT_SYSINFO won't be present to give the guest libc the location of the vdso routine to call.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]