Re: Unmodified driver reuse and Afterburner

On Fri, 22 Jun 2007 14:11:55 +0200, Joshua LeVasseur wrote:

Thank you very much for answering so thoroughly to my questions.

>
>
>> 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.
>

But, these Microsoft/Intel/VMWare technologies are not L4-specific, aren't they? These
technologies are probably, Xen or VMWare specific. The question remains, can these
technologies be adopted to other hypervisors, like L4...

>
>You probably could reuse unmodified Windows drivers if you have some  
>source-code base that conforms to the driver API (maybe that is  
>ReactOS?). 

Yes, ReactOS is the Opensource Windows NT clone, aiming at binary compatibility
with windows applications and drivers (http://www.reactos.org/)

> 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.
>

But are these possibilities (using Virtual Interrupt Flag and VT domains with newer AMD and
Intel processors) open to L4 applications?

>
>> 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.
>

So, as I understood, just privileged instructions cause traps, which
are handled by Wedge. Wedge (aka VMM) handles a TRAP, correcting
the result of an instruction, which caused this trap. And for the trap to be handled
successfully, the virtualization-sensitive instruction must be patched (the afterburner
adds extra space after the instruction, by NOP'ping, and during the OS loading, this 
place is patched by Wedge), if it is not patched, then this cause the TRAP to be
handled unsuccessfully. So, the "unauthorized" code of an OS in VM differs from 
"authorized" one in that it is not patched, and, so, the traps caused by these instructions
are handled unsuccessfully, so, such a program just traps (or "segfaults", in other words).
Am I right?


>
>>
>> 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.
>

And how then the mapper determines, that the driver belongs to a certain 
device class? Is this done by writing a class for each driver in some config
file? Or, the mapper just examines, what devices are in the system, and 
which drivers operate which device, and so, determining the class of a driver
by the class of a device it operates?

>
>
>Josh
>
>