> - The AMD docs contain one odd sentence:
> "The CS and SS registers must not be modified by the operating system
> between the execution of the SYSCALL and the corresponding SYSRET
> instruction".
As I understand it is:
SYSCALL does not actually load the new CS/SS from the GDT,
but just set the internal base/limit/descriptor valid registers to
"flat" values. SYSEXIT undo this. When the SYSRET is executed the
selector should be still the same, otherwise the resulting state may not be
exactly the same as when SYSCALL happend.
But if you make sure that CS/SS have the same state on SYSRET then
everything should be ok. This means a context switch to a process with
possibly different CS/SS values should be ok.
The GDT is guaranteed to stay constant and SYSCALL forbids use of an
LDT for SS/CS.
I have not actually tried this on an Athlon, but on x86-64 with
entering long mode it works (including context switches to processes with
different segments etc.)
To add to confusion there are three different all slightly different
SYSCALL flavours:
K6 (unusable iirc), Athlon/Hammer with 32bit OS
(would work, but they have SYSENTER too so it makes sense to just share code
with Intel), Hammer with 64bit OS (working, has to use SYSCALL from both
32bit and 64bit processes)
They are different in what registers they clobber and how EFLAGS is handled
and some other details.
On x86-64 SYSCALL is the only and native system call entry instruction
for 64bit processes. The only reason to use SYSCALL from 32bit programs is
that on a x86-64 SYSENTER from 32bit processes to 64bit kernels is not
supported, so the 2.5.53 x86-64 kernel implements the AT_SYSINFO vsyscall
page using SYSCALL.
> Is SYSCALL+iretd permitted? That's needed for execve, iopl, task
Yes, it works.
> switches, signal delivery.
> What about interrupts during SYSCALLs?
SYSCALL in 32bit mode turns off IF on entry (in long mode it is configurable
using a MSR)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/