I'd have to scour the wine source to verify that.
> > I don't know about Intel's SYSENTER/SYSEXIT, but with AMD's
> > SYSCALL/SYSRET you cannot return to user space with iret after a
> > SYSCALL. The CPU sets an internal flag that causes a GPF when
> > anything modifies %cs except for SYSRET or an interrupt (hardware or
> > software). This has been a big stumbling block for me with adding
> > SYSCALL support becuase it interferes with task switching (ie. can't
> > switch to another task that would do an iret), unless it is restricted
> > to syscalls that cannot sleep.
>
> i've just tested this on Xeon CPUs, and it works. (i forced the fastcall
> entry point to reschedule unconditionally, the system still uses int $80)
>
> I agree that this would be a serious showstopper. Are you sure you werent
> bitten by the stack-MSR issue? (we have to reload the SYSENTER kernel-ESP
> MSR on every task switch)
Positive. The kernel stack pointer isn't set with the K6's MSR, which
is unfortunate. Only %cs, %ss, and the kernel entry point are set.
%esp still points to the userspace stack after SYSCALL and must be
reloaded with the kernel's stack manually, which will be very tricky in
an SMP environment if/when Athlon SMP systems appear.
There are two versions of the SYSCALL support. Version 1 is on the K6
and K6-2's before stepping 8, and version 2 is later K6-2s, the K6-3,
and I presume the Athlon. My testing was done with version 1. I now
have a K6-2 with the version 2 support and I will run some tests later
tonight. As far as I know, the only difference between versions is in
how %cs and %ss are set upon SYSRET.
Documentation on SYSCALL/SYSRET can be found at
http://www.amd.com/K6/k6docs/pdf/21086.pdf
--Brian Gerst
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/