Re: Unmodified driver reuse and Afterburner

On Jun 20, 2007, at 2:09 PM, Valery V. Sedletski wrote:

> I'm contributing to an OS/2 cloning project (www.osFree.org) and  
> there is some hope to reuse unmodified
> Linux device drivers. Here, the L4Ka Unmodified driver reuse and  
> Afterburner projects seem to be very
> promising. But I still have some questions that are not clear. So,  
> can someone answer the questions regarding
> these technologies?
>
> 1)  The web page about Unmodified driver reuse project states that  
> Linux drivers are unmodified. Does that
> mean that they are unmodified in their _source_code_ form, but  
> recompilation is required? Or, they remain
> unmodified in their binary form? (Is there a possibility to be  
> binary compatible with native Linux?)

With para-virtualization, the driver source code is unchanged, but  
you must recompile.  With pre-virtualization, you can use binaries  
that execute both on raw hardware and in the VM.  So if binary  
compatibility is necessary (because you don't have the source code  
for the driver), then you can achieve it if you convince the driver's  
vendor to run the pre-virtualization tools for you.  Potentially in  
the long run that will happen automatically due to Linux's  
paravirt_ops project.

>
> 2)   As I understand, Linux drivers are platform-neutral. So, they  
> are probably do not work with hardware
> directly, but instead, call routines in architecture-specific part  
> of kernel, which operate hardware directly.
> So, only architecture-specific part of kernel must be modified to  
> paravirtualize Linux kernel. And drivers remain
> untouched. (Maybe, even no recompilation required). Am I right?

Drivers use inlined functions and macros, so on some level they will  
change, and will thus require recompilation.  For Linux, this  
particularly concerns enabling/disabling interrupts, saving the  
interrupt status, and spin locks (which maybe disable interrupts).


> 3)  Is the unmodified driver reuse project and L4Ka virtualisation  
> technologies all Linux or UNIX specific?
> Does they rely on some Linux features (drivers platform neutrality  
> etc.). Or, is it possible to reuse unmodified
> Windows drivers? If there is a possibility to paravirtualise  
> ReactOS kernel by using Afterburner project, then, is
> a source code for Windows device drivers required?

The technologies are not Linux/UNIX specific.  Both Intel and  
Microsoft use the approach for reusing Windows drivers in VMs in  
their research projects.  VMware has always done something similar  
for their hosted hypervisor.

You probably could reuse unmodified Windows drivers if you have some  
source-code base that conforms to the driver API (maybe that is  
ReactOS?).  I don't know whether Windows drivers access privileged  
instructions.  If they do, you'd just have to be willing to do some  
more heavy weight virtualization.   You'd probably only need to  
virtualize the interrupt flag, and even that might be possible using  
the x86 virtual interrupt flag.  And with newer chips you have the  
option to run the Windows drivers in VT domains.

> 4)  Must be the Operating System sources, for which Afterburner is  
> applied to, to be 32-bit clean, or they
> (sources) can contain 16-bit code? (Maybe, it is possible to use  
> Afterburner with OS/2 sources? These
> sources contain 16-bit parts along with 32-bit ones)

The current Afterburner has no support for 16-bit code.  It probably  
could be adapted to 16-bit code.

> 5)  What are "virtualisation-sensitive" instructions, modified by  
> afterburner? Are they just privileged instructions
> or something else?

Virtualization-sensitive instructions are a superset of the  
privileged instructions.  Only the privileged instructions cause  
traps that permit a VMM to virtualize the OS.  The problem is that  
x86 has many system instructions that user-level can execute, and  
which will return unexpected data to a guest OS, because the  
instructions offer the VMM no chance to intercede and fix up the  
data.  Newer chips from Intel and AMD have special virtualization  
modes that fix the problem.


>
> 6)  The Device Driver Reuse project is based on the mapper  
> application inside Device driver OS (DD/OS).
> The Client OS calls this mapper and it translates this request into  
> the form, specific to DD/OS kernel. The
> question is: is the individual support for each reused device  
> driver required in this mapper, or the mapper is
> "driver-independent"? How can this be made (driver independence)?  
> The ioctl requests to different drivers are
> different, so, it seems that the specific support is required in  
> mapper for each driver. (In other words, there is
> support in mapper for HDD driver and LAN card driver, for example.  
> But if we want to add a new driver to
> DD/OS, must the mapper be modified or not? So, must the mapper  
> support each driver specifically (is this
> support hardcoded in mapper), or is it general for different drivers?)

The mapper is specific to a class of drivers, and like any driver  
modularization, it provides a lowest common denominator for the  
devices' features.  If a new device comes along with features that  
exceed the abstractions of the OS or of the mapper, then one must  
update all layers to take advantage of those new features.  You don't  
have to update the mapper to support each new device in a particular  
device class.



Josh