Re: VKernel progress update - 8 Jan 2006 (milestone reached!)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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