lkml.org 
[lkml]   [1999]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectAMD SYSCALL support
Brian Gerst wrote:
> > > 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.

I just tested iret after syscall on my K6-2, and it does work. It looks
like the old version of SYSCALL isn't worth supporting then, as it has
other problems with the return to user mode as well. I'm working on an
equivalent of your SYSENTER patch. One concern I have however is that
currently entry.S is a mess of spaghetti code (for good reason
unfortunately), and all these alternate syscall entries are making it
much worse.

--

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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.085 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site