Information Technology Reference
In-Depth Information
opaque pointer parameters to the ioctl call for
sound-card drivers. The shadow sound-card
driver relies on this standard to interpret and
log ioctl requests.
In preparation for recovery, the shadow garbage
collects resources held by the driver. To ensure
that the kernel does not see the driver “disappear”
as it is restarted, the shadow retains objects that
the kernel uses to request driver services. For
example, the shadow does not release the device
object for network device drivers. The remaining
resources, not needed for recovery, are released.
Active-Mode Recovery
The shadow enters active mode when a failure
is detected in a driver. A driver typically fails by
generating an illegal memory reference or pass-
ing an invalid parameter across a kernel interface.
Nooks' failure detectors notice the failure and
notify the Nooks Isolation Manager, which in
turn invokes the shadow recovery manager. This
manager immediately locates the corresponding
shadow driver and directs it to recover the failed
driver. The shadow driver's task is to restore the
driver to the state it was in at the time of failure, so
it can continue processing requests as if it had never
failed. The three steps of recovery are: (1) stopping
the failed driver, (2) reinitializing the driver from
a clean state, and (3) transferring relevant shadow
driver state into the new driver. Unlike Nooks'
restart recovery manager, a shadow driver does
not completely unload the failed driver.
Reinitializing the Driver
The shadow driver next “boots” the driver from
a clean state. Normally, booting a driver requires
loading the driver from disk. However, the disk
driver may not be functional during recovery.
Hence, the driver code and data must already be
in memory before a failure occurs. For this reason,
the shadow caches a copy of the device driver's
initial, clean data section when the driver is first
loaded. These data sections tend to be small. The
driver's code is already loaded read-only in the
kernel, so it can be reused from memory.
The shadow boots the driver by repeating
the sequence of calls that the kernel makes to
initialize a driver. For some driver classes, such
as sound-card drivers, this consists of a single
call into the driver's initialization routine. Other
drivers, such as network interface drivers, require
additional calls to connect the driver into the
network stack.
As the driver restarts, the shadow reattaches the
driver to the kernel resources it was using before
the failure. For example, when the driver calls the
kernel to register itself as a driver, the taps redirect
these calls to the shadow driver, which reconnects
the driver to existing kernel data structures. The
shadow reuses the existing driver registration,
passing it back to the driver. For requests that
generate callbacks, such as a request to register
the driver with the PCI subsystem, the shadow
emulates the kernel and calls the driver back in
the kernel's place. The shadow also provides
the driver with its hardware resources, such as
interrupt request lines and memory-mapped I/O
regions. If the shadow had disabled these resources
Stopping the Failed Driver
The shadow recovery manager begins recovery
by informing the responsible shadow driver that
a failure has occurred. It also closes the taps,
isolating the kernel and driver from one another's
subsequent activity during recovery. After this
point, the tap redirects all kernel requests to the
shadow until recovery is complete.
Informed of the failure, the shadow driver first
invokes the isolation service to preempt threads
executing in the failed driver. It also disables the
hardware device to prevent it from interfering
with the OS while not under driver control. For
example, the shadow disables the driver's interrupt
request line. Otherwise, the device may continu-
ously interrupt the kernel and prevent recovery. On
hardware platforms with I/O memory mapping, the
shadow also removes the device's I/O mappings
to prevent DMAs into kernel memory.
Search WWH ::
Custom Search