vkernel & GSoC, some questions

[Alexander Sack]

Some interesting reading for anyone who cares:

http://citeseer.ist.psu.edu/rd/89980079%2C480988%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/24361/http:zSzzSzwww.usenix.orgzSzpublicationszSzlibraryzSzproceedingszSzusenix01zSzsugermanzSzsugerman.pdf/venkitachalam01virtualizing.pdf

> These shortcuts are going to be considerably more efficient, resulting
>    in better performance.  It is also the claim to fame that a vkernel
>    architecture has.  In fact, XEN is really much closer to a vkernel
>    architecture then it is to a hypervisor architecture.  A vkernel can
>    be thought of as the most generic and flexible implementation, with
>    access to many system calls verses the fairly limited set XEN provides,
>    and a hypervisor's access to the same subset is done by emulating
>    hardware devices.

I've never used XEN (paravirtualization) but I assume that the target
OS then has special system calls or shortcuts to ask the underlying
monitor/hypervisor to the right things (like allocate safe (virtual)
memory instead of relying on a shadow/trap model etc.).

>    In all three cases the emulated hardware -- disk and network basically,
>    devolves down into calling read() or write() or the real-kernel
>    equivalent.  A hypervisor has the most work to do since it is trying to
>    emulate a hardware interface (adding another layer).  XEN has less work
>    to do as it is really not trying to emulate hardware.  A vkernel has
>    even less work to do because it is running as a userland program and can
>    simply make the appropriate system call to implement the back-end.

I'm pretty sure this is what VMWare does for the their hosted product.
 Its a simple userland process that makes syscalls and traps
interrupts which eventually devolve into reads and writes.  I believe
they do a lot of performance work in interrupt coalescing and doing
their darnest to prevent world-wide context switches.

>  There are more similarities then differences.  I expect VMWare is feeling
>    the pressure from having to hack their code so much to support multiple
>    operating systems... I mean, literally, every time microsoft comes out
>    with an update VMWare has to hack something new in.  it's really amazing
>    how hard it is to emulate a complete hardware environment, let alone do
>    it efficiently.

No doubt virtualization is a tough job and I'm wondering if future
hardware enhancements will make software like VMWare/vkernel/XEN
obsolete in the end.

>    Frankly, I would love to see something like VMWare force an industry-wide
>    API for machine access which bypasses the holy hell of a mess we have
>    with the BIOS, and see BIOSes then respec to a new far cleaner API.  The
>    BIOS is the stinking pile of horseshit that has held back OS development
>    for the last 15 years.

EFI?  Just kidding...

-aps

-- 
"What lies behind us and what lies in front of us is of little concern
to what lies within us." -Ralph Waldo Emerson