> As far as I know, Wine currently only uses the extra segments for
> Windows code. Any Linux syscalls should only be coming from the main
> code segment.
that is great. No changed %ds, %es, %ss either when glibc is called?
> 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)
-- mingo
-
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/