From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 20:40:55 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479EA1065682 for ; Mon, 17 Mar 2008 20:40:55 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by mx1.freebsd.org (Postfix) with ESMTP id B21598FC23 for ; Mon, 17 Mar 2008 20:40:54 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by gv-out-0910.google.com with SMTP id n40so1179859gve.39 for ; Mon, 17 Mar 2008 13:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LN07GVxq6l3h2T+vCsUxalJx0VsGnpbFrFJ0oSy/PD0=; b=gzri8L/7opCo+37dvDRo7WUV9sEKUDcr9tZ1KHwdE6v8A2VnTkN19iaS9J4xNuEqSV2jfgT36/sKz6O6Q68tOQxw0NzqtLup5Q9fZ8/6ThhqFsK0Ft7UNnyFBdeo2r9Y2zyL6+L7nbm7PZuk5tiTsHriyaeu15tc06BehAnwhzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GGJ8LsUSQAFaOMHdwpnszZwoeNp712GMxiEm6hGxgJW9iszEXnjL1Z98ESkkeWrQ+/ELzyoFYEP9sfJsyTJ9k1zKtK2HsUZjrshqxCyrauSs/Ra93DGucXQXBJxEDgdRhrU1ThqInq0aa1rcmPvPBTbD6vvf1tO5hr9mQQ5Gwwc= Received: by 10.150.199.21 with SMTP id w21mr416937ybf.8.1205786452412; Mon, 17 Mar 2008 13:40:52 -0700 (PDT) Received: by 10.150.230.16 with HTTP; Mon, 17 Mar 2008 13:40:52 -0700 (PDT) Message-ID: <3c0b01820803171340w58918956nace0044a3506ac28@mail.gmail.com> Date: Mon, 17 Mar 2008 16:40:52 -0400 From: "Alexander Sack" To: "Matthew Dillon" In-Reply-To: <200803172016.m2HKGfjA020263@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080316122108.S44049@fledge.watson.org> <200803162313.m2GNDbvl009550@apollo.backplane.com> <3c0b01820803171243k5eb6abd3y1e1c44694c6be0f6@mail.gmail.com> <200803172016.m2HKGfjA020263@apollo.backplane.com> Cc: jgordeev@dir.bg, "Andrey V. Elsukov" , Robert Watson , freebsd-hackers@freebsd.org Subject: Re: Re[2]: vkernel & GSoC, some questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 20:40:55 -0000 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