 |
| Author |
Message |
|
|
 Posted: Aug 20, 2007 - 02:45 PM |
|
Joined: May 02, 2007
Posts: 30
Location: Sydney, Australia
|
|
Is there anyway to get the AVR32AP to disable interrupts on a scall instruction. This is a particular problem for a microkernel like OKL4 where the user context needs to be saved before handling the interrupt as preemption is likely and the RAR_SUP/RSR_SUP will be overwritten.
This makes handling interrupts a problem as the kernel needs to detect the case when the user context has not yet been saved. This leads to a more complicated and slower interrupt handling code. If the option to simply disable interrupts on a scall instruction existed, register state could be safely saved before interrupts are re-enabled.
I've also been looking through the Linux code trying to understand how Linux handles this. In the case when preemption is enabled, I can't find where the RAR_SUP/RSR_SUP are saved when an interrupt occurred in kernel mode just before the scall handler had got to reading these two registers. It seems to me there values could be overwritten. Please point out if I've missed something.
--
Carl |
|
|
| |
|
|
|
|
|
|
Posted: Aug 22, 2007 - 08:12 AM |
|
Joined: Sep 14, 2003
Posts: 4209
Location: Queanbeyan, Australia
|
|
FWIW kernel preempt in Linux is known to cause the occasional unexplained segfault, I wonder if this is the reason..? (Or was known to cause this at least, last time I checked..)
-S. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 22, 2007 - 10:50 AM |
|
Joined: Apr 26, 2006
Posts: 1076
Location: Trondheim, Norway
|
|
I think you're right -- this might very well be the reason why preempt on avr32 is buggy. I also think it would simplify things to automatically set the GM bit before running an interrupt handler, not only the system call handler.
I guess the problem is how to do this without breaking architecture compatibility, but it might be ok if it's optional (i.e. controlled by a bit in CPUCR or something?)
Until this has been addressed (with two completely different OSes having run into the issue, it will hopefully happen pretty soon) I guess you can work around the issue by doing something like this:
o Make "ssrf 16" the first instruction in the system call handler.
o In the interrupt handler, compare the address in RAR_INTx with the address of the "ssrf 16" instruction. If they match, set the GM bit in RSR_INTx and return.
o The system call handler can now do all the housekeeping it wants with interrupts disabled. When interrupts are re-enabled afterwards, the interrupt handler will be executed immediately.
At least that's the theory. Hopefully I didn't miss anything.
This adds some code to the interrupt handler, but not all that much. Assuming you have to load RAR_INTx anyway, you only need a sub instruction for loading the address of the syscall handler, a cp.w instruction and a branch (not taken in the normal case.) The uncommon case is a bit worse since you need to re-enter the interrupt handler, but it shouldn't add more than a couple of dozen cycles and it should almost never happen. |
|
|
| |
|
|
|
|
|
|
Posted: Dec 11, 2008 - 09:10 PM |
|
Joined: Oct 12, 2008
Posts: 15
|
|
|
Quote:
o In the interrupt handler, compare the address in RAR_INTx with the address of the "ssrf 16" instruction.
Please can you explain that a little bit better.
Thanks |
|
|
| |
|
|
|
|
|
|
|
FAQ •
Search •
Register •
Log in to check your private messages
Log in
• 
Minimize
• 
RSS
