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.mehn...@oracle.com
<mailto:frank.mehn...@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 <redwo...@gmail.com
<mailto:redwo...@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...@gmail.com
<mailto:luca.carotenuto...@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
> > redwo...@gmail.com <mailto:redwo...@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@virtualbox.org <mailto:vbox-dev@virtualbox.org>
https://www.virtualbox.org/mailman/listinfo/vbox-dev
--
Luca Carotenuto
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
