Task protection using ARM9

[Craig S. Steele]

At 12:11 PM -0500 6/29/07, Charles Steaderman wrote:
>We have employed just this method (two distinct "applications" 
>chosen at boot time) on previous projects. Unfortunately, this 
>project does not have quite so clear a modal distinction between the 
>two application feature sets. And there is a case where both need to 
>execute at the same time. While I agree that the additional overhead 
>for the inclusion of "thread protection data" in the context switch 
>would add some time, I believe that the processor that we have 
>chosen would have no trouble keeping up. I am more interested in 
>everyone's feeling about scope of work, how much of the RTEMS kernel 
>would be affected, etc. The other piece that would need to be 
>handled would be access exception handlers, although this would be 
>application specific.

If you've got the CPU performance to tolerate a fixed-ratio 
round-robin scheduling and a heavyweight context switch, you could 
implement a very-low-level virtual machine abstraction layer 
underneath RTEMS and periodically switch between the two virtual 
machines, with a full (possibly lazy) register and ATU context 
switch.  If you've got a reasonable ATU and adequate data memory, you 
could run two text-segment-shared copies of RTEMS as a 
time-multiplexed dual processor with shared-memory communications. 
If you wanted to be serious about the protection, you'd have to run 
RTEMS and the application code in user mode, which would (a) require 
ferreting out all RTEMS privileged-mode instructions and register 
access and putting that code in supervisor-mode SYScalled routines in 
the VMAL, (b) figuring out appropriate device mappings in the (two) 
address maps if you want direct user-mode device access, and (c) 
working out an exception handling registration system in the 
supervisor-mode VMAL for user-mode exception-event upcall handlers. 
This sounds like a lot, but I think a clean partition is possible, 
and the idea of mapping multiple virtual machines onto a set of 
physical machines is probably one of the easier migrations paths to a 
multi-core future :-)

Craig