Code: Select all
section .data
%define MAXAPIFUNCTION 4
APItable:
dd firstFunction
dd APIundefined
dd secondFunction
dd APIundefined
section .text
APIundefined:
mov eax,errFuncNotDefined
ret
APIsoftIntHandler:
cmp eax,MAXAPIFUNCTION
ja .notdefined
call [APItable+eax*4]
iretd
.notdefined
mov eax,errFuncNotDefined
iretd
APIcallGateHandler:
cmp eax,MAXAPIFUNCTION
ja .notdefined
call [APItable+eax*4]
retf
.notdefined
mov eax,errFuncNotDefined
retf
APIsysenterHandler:
cmp eax,MAXAPIFUNCTION
ja .notdefined
call [APItable+eax*4]
sysexit
.notdefined
mov eax,errFuncNotDefined
sysexit
APIsyscallHandler:
cmp eax,MAXAPIFUNCTION
ja .notdefined
mov [kernelStackTop],esp
mov esp,kernelStack-4
sti
call [APItable+eax*4]
pop esp
sysret
.notdefined
mov eax,errFuncNotDefined
sysret
Code: Select all
%macro APIcall 1
mov eax,%1
%ifdef INTEL
push ecx
push edx
mov ecx,esp
mov edx,%%l1
sysenter
pop edx
pop ecx
%elifdef AMD
syscall
%elifdef CALLGATE
call APICALLGATESEL:0x00000000
%else
int APIINT
%endif
%%l1:
%endmacro
If you try to write something in SYSENTER MSRs you'll get GP Fault first.Brendan wrote:
If the CPU doesn't support sysenter and/or syscall you can emulate them within the invalid opcode exception handler.
And also they call it 'fast system call' if you emulate it with UD fault then it is not so fast.IA-32 Intel Architecture
Software Developer?s
Manual
Volume 2:
The SYSENTER instruction is optimized to provide the
maximum performance for system calls from user code running at privilege level 3 to operating
system or executive procedures running at privilege level 0.
Then don't. The idea is, the userland code can call SYSENTER regardless. The OS obviouls needs to modify its own behavior based on the actual hardware present. The idea is non-OS software shouldn't have to (unless you're designing an exokernel).kataklinger wrote:If you try to write something in SYSENTER MSRs you'll get GP Fault first.Brendan wrote:If the CPU doesn't support sysenter and/or syscall you can emulate them within the invalid opcode exception handler.
Now the speed question is a very good question. I'd be interested in any hard figured anyone has on this, too. But how much slower can it be to handle system calls through the #UD fault vector than through the INT 0x80 vector? My off-the-cuff reaction to this idea is, not bad -- on hardware that supports it, you syscalls go very fast, and on hardware that doesn't, they're about the same speed as if you were using some other syscall method like trap gates or call gates, no?kataklinger wrote: and what about speed?
And also they call it 'fast system call' if you emulate it with UD fault then it is not so fast.IA-32 Intel Architecture
Software Developer?s
Manual
Volume 2:
The SYSENTER instruction is optimized to provide the
maximum performance for system calls from user code running at privilege level 3 to operating
system or executive procedures running at privilege level 0.
Emulating sysenter and/or syscall would be slower. My original idea was that applications could use what-ever they think is best for the situation. For example, if you're writing a utility that measures the cache bandwidth on Athlon CPUs then you probably won't care about emulation on non-Athlon CPUs. If an application has a function that must have the highest performance on all 80x86 CPUs it could check what the CPU supports and have 3 different versions of the function. Also software can be distributed as source code and optimized/compiled for the target machine, so that the fastest method is used each time it's compiled.kataklinger wrote: Well, UD handler will be more complex and more slower. And your OS will be less portable.
I will stick to software interupts because they make my life easier.
I don't see why it would be much more complex, nor more than a few cycles slower (one more memory access and a comparison would be all you'd need). And it wouldn't be ANY more or less portable -- setting the IDT vector for INT 0x80 isn't any more portable than setting the IDT vector for #UD.kataklinger wrote: Well, UD handler will be more complex and more slower. And your OS will be less portable.