Machine state on entry to fsyscall handler¶

r10	0
r11	saved ar.pfs (a user-level value)
r15	system call number
r16	“current” task pointer (in normal kernel-mode, this is in r13)
r32-r39	system call arguments
b6	return address (a user-level value)
ar.pfs	previous frame-state (a user-level value)
PSR.be	cleared to zero (i.e., little-endian byte order is in effect)
	all other registers may contain values passed in from user-mode

Required machine state on exit to fsyscall handler¶

r11	saved ar.pfs (as passed into the fsyscall handler)
r15	system call number (as passed into the fsyscall handler)
r32-r39	system call arguments (as passed into the fsyscall handler)
b6	return address (as passed into the fsyscall handler)
ar.pfs	previous frame-state (as passed into the fsyscall handler)

Fsyscall handlers can execute with very little overhead, but with thatspeed comes a set of restrictions:

• Fsyscall-handlers MUST check for any pending work in the flagsmember of the thread-info structure and if any of theTIF_ALLWORK_MASK flags are set, the handler needs to fall back ondoing a full system call (by calling fsys_fallback_syscall).
• Fsyscall-handlers MUST preserve incoming arguments (r32-r39, r11,r15, b6, and ar.pfs) because they will be needed in case of asystem call restart. Of course, all “preserved” registers alsomust be preserved, in accordance to the normal calling conventions.
• Fsyscall-handlers MUST check argument registers for containing aNaT value before using them in any way that could trigger aNaT-consumption fault. If a system call argument is found tocontain a NaT value, an fsyscall-handler may return immediatelywith r8=EINVAL, r10=-1.
• Fsyscall-handlers MUST NOT use the “alloc” instruction or performany other operation that would trigger mandatory RSE(register-stack engine) traffic.
• Fsyscall-handlers MUST NOT write to any stacked registers becauseit is not safe to assume that user-level called a handler with theproper number of arguments.
• Fsyscall-handlers need to be careful when accessing per-CPU variables:unless proper safe-guards are taken (e.g., interruptions are avoided),execution may be pre-empted and resumed on another CPU at any giventime.
• Fsyscall-handlers must be careful not to leak sensitive kernel’information back to user-level. In particular, before returning touser-level, care needs to be taken to clear any scratch registersthat could contain sensitive information (note that the currenttask pointer is not considered sensitive: it’s already exposedthrough ar.k6).
• Fsyscall-handlers MUST NOT access user-memory without firstvalidating access-permission (this can be done typically viaprobe.r.fault and/or probe.w.fault) and without guarding againstmemory access exceptions (this can be done with the EX() macrosdefined by asmmacro.h).

The above restrictions may seem draconian, but remember that it’spossible to trade off some of the restrictions by paying a slightlyhigher overhead. For example, if an fsyscall-handler could benefitfrom the shadow register bank, it could temporarily disable PSR.i andPSR.ic, switch to bank 0 (bsw.0) and then use the shadow registers asneeded. In other words, following the above rules yields extremelyfast system call execution (while fully preserving system callsemantics), but there is also a lot of flexibility in handling morecomplicated cases.