Syscalls and RSE

[Christian Kandeler]

On Thursday 21 June 2007 19:41, Marcel Moolenaar wrote:

> When we switch to the kernel stack, we align BSPSTORE to the user stack
> (WRT to NaT collections). In other words we preserve the least
> significant 9 bits of BSPSTORE. Since these bits determine when a NaT
> collection will happen and which bit in the RNAT register will take the NaT
> bit of the stacked register on a flush, we effectively preserved all the NaT
> bits without explicitly saving or restoring anything.

Yes, I understand that.

> As such, we never clobber "used" bits in the RNAT register and it also
> allows us to flush the dirty registers onto the kernel stack and copy
> them back to user space knowing that any NaT collections on the kernel stack
> will be copied to the right location on the user stack. Also, any NaT
> bits left in RNAT after the loadrs on our way out of the kernel will be
> those of the user process.

The problem, I think, is not the RNAT on the way out of the syscall, but a 
collection of undefined NaT bits saved in the kernel and loaded later in user 
space. As I have mentioned in my first mail, this is due to the fact that we 
can advance the saved user space BSPSTORE (and therefore BspLoad too) over 
such a NaT collection in ia64_flush_dirty().
The reason that this does not usually lead to problems in practice is probably 
that the current Itanium processors set RNAT to zero after a backing store 
switch, so no NaT bits are actually set to 1 by the RSE load that restores 
the undefined NaT collection. This is not guaranteed, of course.
I've tried to verify my theory, and I believe I have succeeded: If the code in 
epc_syscall is correct, then it should tolerate any value in RNAT after the 
backing store switch, since the value of this register is undefined anyway. 
However, when I manually set RNAT to -1 and boot the resulting kernel, the 
system crashes right after entering user space (Illegal Instruction in the sh 
process). I assume this is due to one of the many NaT bits the process 
receives after making a system call.

Regards,
Christian Kandeler