[vbox-dev] Questions about the Host Drivers

Knut St. Osmundsen bird at sun.com
Tue Jan 26 01:25:46 PST 2010

Jiaqing Du wrote:
> Hi List,
> I just started to read the code. It seems that for a particular OS,
> the corresponding host driver consists of two parts: a support driver
> and a common binary image. First the support driver is loaded to the
> kernel, then the common binary image is loaded from user land to the
> kernel and becomes part of the host driver.
> My question is that how to manipulate variables and call functions
> located in one side while we are in the other side. For instance, I
> want to read&write some files in VMCPU from the linux support driver.
> Are there any example code snippets in the code repository? Are there
> any discussions about the design of this common binary image + support
> driver arch?

There are currently three image that gets loaded via the support driver
(SUPDrv): VMMR0.r0, VBoxDDR0.r0 and VBoxDD2R0.r0.  They don't really
become part of the SUPDrv, it is just a facility to (1) load them and
(2) call into them. (*)  The SUPDrv is a generic facility and designed
such that, if we don't make changes to it, it can be used across
VirtualBox versions where the major VirtualBox structures like VM and
VMCPU changes.  This means that in it's current form the SUPDrv doesn't
want to know any details about the VMCPU structure nor the VM structure.

That said, there aren't any technical or practical issues with accessing
the internals of a VM from the support driver, only there are no sample
code for doing.  Since your ideas are very vague I cannot give any hints
about how to go about what you wish to archive either.

(*) The SUPDrv has other tasks, for instance: (3) Connecting the network
drivers (VBoxNetFlt and VBoxNetAdp) with the internal network switch
(IntNet) using a object factory (service) registry.  (4) Providing
generic and simple object management that is used for doing access
control on VMs, networks and similar.  (5) Provide the ring-3 part of
the VMM with a more powerful memory API.  (6) Provide all 3 VMM contexts
with a high resolution time source via the global info pages (GIP).  (7)
Provide a portable API to the *.r0 modules with help from the runtime


Kind regards / Mit freundlichen Gruessen / Vennlig hilsen,


Sun Microsystems GmbH        Knut St. Osmundsen
Werkstrasse 24               Senior Staff Engineer, VirtualBox
71384 Weinstadt, Germany     mailto:bird at sun.com

Sitz der Gesellschaft: Sun Microsystems GmbH,
Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder,
Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

More information about the vbox-dev mailing list