\begin{figure*}
\centering
\includegraphics[keepaspectratio=true,width=6in]{figures/pdf/synergy.pdf}

\caption{\small \bf Walk through of on-demand fault tolerance when specific driver entry points
are isolated on-demand during a successful execution and during a crash.}

\label{fig:synergy}
\vspace{-0.2in}
\end{figure*}

\section{Synergy of isolation and recovery}


In order to correctly 
recover from these exceptions, on-demand fault tolerance need to appropriately restore 
stack and register values and return correctly. In such scenarios of fatal kernel traps,
on-demand fault tolerance restore the processor and register values, resetting the instruction
pointer to when the control has just been transferred to the SFI module, with the failure
bit being set. At this point, returns an error to the main kernel module by immediately
checking the failure bit upon return. The stack pointer is correctly restored, since we
restore the stack pointer from processor snapshot captured when control just transfers to
the SFI module.  

In this section, we describe how driver failures are detected and walk through a scenario
of how the isolation and recovery system cooperate to provide on-demand fault tolerance

\subsection{Detecting driver failures}
As mentioned earlier, On-demand isolation employs weak type safety provided by SFI and
hardware fault detection to detect driver failures. Since on-demand isolation only marshals
the required fields in data structure that are accessed by the isolated entry points, we
are able to provide fine grained memory protection by storing these values in range hash tables.
When a failure is detected during an SFI check, isolated entry point unwinds execution and
returns an error to the main module. Also, when a failure bit is set, the marshaling and
de-marshaling code is skipped as the stack unwinds. 



\subsection{Walkthrough of on-demand fault tolerance}
