Date: Mon, 17 Mar 2008 16:40:52 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: "Matthew Dillon" <dillon@apollo.backplane.com> Cc: jgordeev@dir.bg, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Robert Watson <rwatson@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: Re[2]: vkernel & GSoC, some questions Message-ID: <3c0b01820803171340w58918956nace0044a3506ac28@mail.gmail.com> In-Reply-To: <200803172016.m2HKGfjA020263@apollo.backplane.com> References: <20080316122108.S44049@fledge.watson.org> <E1JatyK-000FfY-00.shmukler-mail-ru@f8.mail.ru> <200803162313.m2GNDbvl009550@apollo.backplane.com> <3c0b01820803171243k5eb6abd3y1e1c44694c6be0f6@mail.gmail.com> <200803172016.m2HKGfjA020263@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820803171340w58918956nace0044a3506ac28>