[vbox-dev] Fwd: Explanation about Ring0 context
Klaus Espenlaub
klaus.espenlaub at oracle.com
Tue Feb 2 12:42:40 GMT 2016
Hi Luca,
On 02.02.2016 10:50, Luca Carotenuto wrote:
> Hi Frank,
> thanks for your precise answer.
> At this point, there is only two things I don't get:
>
> 1) callback functions for E1000 (e.g. e1kRegWriteTDT()), are executed
> in R0 context (or at least this is what Log says), but I can find the
> relative
> symbols only in VBoxDD.so (which is related to R3), and not in VMMR0.r0.
> How is that possible?
Guess the symbols have been stripped, as they're local and therefore not
needed for dynamic linking. There are no magic jumps between R0 and R3,
it's all done through the registration of handlers, in this particular
case when mapping PCI regions (see e1kMap()), which can be controlled
through the flags fR0Enabled and fRCEnabled which are taken from the
device config.
If there's a R0 handler for some IO or MMIO region, it is used. R0
handlers can return e.g. VINF_IOM_R3_MMIO_WRITE, which conveys the
information that handling this particular request isn't possible in R0
and needs to be retried in R3.
So this isn't as fine grained as you probably imagined from looking at
the code.
> 2) Since I'm writing some code for a new networking driver (for my
> University),
> how can I tell the compiler "compile and run this code in R0, compile
> and run that code in R3"?
There's no magic. Everything is handled by the build process. Ever
wondered why the DevE1000.cpp file shows up so many times in Makefile.kmk?
To compile the necessary parts for each purpose there are some macros
which can be checked. The main one is IN_RING3 which is used quite a bit
in DevE1000.cpp, and that should hopefully make the situation clear.
Klaus
>
> I hope I was clear enough.
>
> Kind regards,
> Luca
>
> 2016-02-02 10:18 GMT+01:00 Frank Mehnert <frank.mehnert at oracle.com
> <mailto:frank.mehnert at oracle.com>>:
>
> Hi Luca,
>
> device emulation code in VirtualBox can run within three contexts:
>
> * R3 (part of VBoxDD): Normal userland code executed in the VM
> process context. This code is executed each time we leave the
> guest and go back to userland. This code is not that performance-
> critical, e.g. device initialization, memory allocation etc.
>
> * R0 (part of VMMR0): Code which is executed in kernel context.
> This happens if the VM runs in VT-x/AMD-V mode and we left the
> VM and entered the root mode where the VirtualBox VMM runs
> (next to the host OS kernel). For performance reasons we don't
> switch to userland (R3). The amount of R0 code is much smaller
> than the amount of R3 code. Such code can also call host OS
> kernel functions directly (e.g. submit a network IP packet to
> the host OS network layer). Calling the host OS code from VMMR0
> is usually done using SUPR0* functions which are implemented in
> src/VBox/HostDrivers/Support and runtime functions which are
> implemented in src/VBox/Runtime/r0drv
>
> * RC/GC (part of VMMRC.rc): This code is executed if the VM runs
> in non VT-x/AMD-V mode (legacy). Only 32-bit code. This code is
> part of the hypervisor which runs in R0 in the context of the
> guest process. The guest itself runs at R1 (guest userland as
> R3 as usual). Google should explain you x86 ring compression.
>
> Of course R3 code cannot directly call R0 code. The code in our
> device driver has sections which are unique to two or all three
> contexts. That means that this code is compiled three times and
> exists in all three contexts. Other code is exclusively used in
> one or two contexts.
>
> Kind regards,
>
> Frank
>
> On Tuesday 02 February 2016 10:00:55 Luca Carotenuto wrote:
> > Gregory, thanks for the reply;
> > anyway, my question was about R3 context of the host.
> > Since the host must emulate the E1000 behaviour, it doesn't need
> to access
> > the I/O space on the host. So, why does it need to be in R0 context?
> > Also, as far as I know, the file VBoxDD.so is a library for R3
> context, and
> > it has the references
> > for functions running in R0 context (e.g. e1kRegWriteTDT).
> > How can it be possible?
> >
> > Kind Regards,
> > Luca Carotenuto
> >
> > 2016-02-01 16:11 GMT+01:00 Gregory Woodbury <redwolfe at gmail.com
> <mailto:redwolfe at gmail.com>>:
> > > Depending on the CPU architecture, Ring 3 processes cannot
> access the
> > > I/O space without causing a General Protection Exception.
> > >
> > > Callback routines from IO requests are to let the application
> be told
> > > that an operation is completed.
> > > And thus have to be in the application's memory space, but
> they are
> > > actually called from the
> > > kernel in R0 space. There are special provisions in the x86 type
> > > architecture for this, and
> > > the callback routine has only a limited amount of freedom to
> access IO
> > > space.
> > >
> > > In a fully emulated environment, this might not be necessary, but
> > > using the hardware virtualization of KVM/QEMU, to access
> > > the IO space still requires Ring0 privleges. I is a sort of
> > > mind-bending set of restrictions and interactioins until one
> > > gets used to thinking like the system developers did.
> > >
> > >
> > > On Mon, Feb 1, 2016 at 6:59 AM, Luca Carotenuto
> > >
> > > <luca.carotenuto.91 at gmail.com
> <mailto:luca.carotenuto.91 at gmail.com>> wrote:
> > > > 1) As I understand, when we talk about Ring-0 context, we
> refer to
> > > > kernel
> > > > space, while Ring-3 context refers to user space. Am I right?
> > > >
> > > > 2) I'm looking inside the E1000 emulation code
> > > > (/src/VBox/Devices/Network/DevE1000.cpp).
> > > > Assuming that the above is right, for what concerns the
> registers
> > >
> > > callbacks,
> > >
> > > > I do not understand why those callbacks are compiled to be
> executed in
> > > >
> > > > Ring-0 context
> > > > (When I use logging inside those functions, the thread name
> i R0).
> > > > Infact, looking inside the VboxDD.so file in the "out/bin"
> directory
> > >
> > > (using
> > >
> > > > objdump tool), it seems that this code "belongs" to Ring-3
> context,
> > > > so why is it running in Ring-0 context?
> > >
> > > --
> > > G.Wolfe Woodbury
> > > redwolfe at gmail.com <mailto:redwolfe at gmail.com>
>
> --
> Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
> ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt,
> Germany
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstraße 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
>
>
>
> --
> Luca Carotenuto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20160202/70977182/attachment.html>
More information about the vbox-dev
mailing list