VKernel progress update - 8 Jan 2006 (milestone reached!)
Matthew Dillon
dillon at apollo.backplane.com
Wed Jan 10 09:53:12 PST 2007
:Okay, but I guess no other subsystem would benefit from this. However, h=
:ow do you manage to "break out"? You'd have to have some kind of context=
: switching, right?
Right now a virtual kernel runs as a single user process on the real
kernel.
When the virtual kernel needs to 'return to user mode' (i.e. switch to
an emulated user process context), it basically makes a system call
to the real kernel with the context of the user process. The real
kernel swaps out the entire VMSPACE and register context and then
basically just returns from the system call... but now it is running
the emulated user process instead of the virtual kernel.
When the real kernel takes a signal for the virtual kernel process, it
detects that it is running the virtual kernel process in emulated user
process mode and swaps the VMSPACE and register context back in before
delivering the signal.
If the emulated user process takes a fault (like a page fault), the
real kernel detects that is running the virtual kernel process in
emulated user process mode and swaps the VMSPACE and register context
back in, and then simply passes the fault context to the virtual kernel
by returning from the original system call virtual kernel made to
run the emulated user context (that is, the real kernel does not
normally process the fault itself.
The real kernel only keeps track of the VMSPACEs for each emulated user
process and the related page tables. Since the page tables are all
throw-away, the real kernel's memory overhead for each emulated user
process created by the virtual kernel is very low.
:> Second, we need some sort of=20
:> pseudo-DMA to handle the transfer... maybe a kernel thread. We hav=
:e
:> the advantage that the transfers to and from the disk only occur
:> from the virtual kernel's 'memory' (which itself is just a memory m=
:apped
:> file), so it would be fairly easy to write a real-kernel kernel thr=
:ead
:> to help out there.
:
:I think that's called aio and is even in POSIX. I think aio should be pu=
:rsued further, just the implementation could need some polishing.
:
:cheers
: simon
AIO is fairly primitive. I don't know if it is possible to make it
do what we need to have done. It would certainly be faster then
SIGIO, but it still wouldn't be optimal.
-Matt
More information about the Kernel
mailing list