Syscalls and RSE

[Marcel Moolenaar]

On Jun 27, 2007, at 5:17 AM, Christian Kandeler wrote:

> 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.

I need think about this for a bit. I'll get back to you shortly...

-- 
Marcel Moolenaar
xcllnt at mac.com