From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: Paravirt KVM capabilities Date: Wed, 10 Jan 2007 10:47:50 +0100 Message-ID: <20070110094750.GA934@elte.hu> References: <20070109141916.GA13276@vlad.carfax.org.uk> <45A3A642.1030604@qumranet.com> <1168384852.19646.161.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Return-path: To: Rusty Russell Content-Disposition: inline In-Reply-To: <1168384852.19646.161.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org * Rusty Russell wrote: > > It's also something for the Linux community in general to decide: if > > we want separate interfaces for paravirtualization and full > > virtualization (lhype and kvm) or a merged interface. I can see > > arguments in favor of both positions. > > Yeah, me too. > > Ignoring technical questions for a moment, the main issue is > that lhype doesn't have an ABI; you have to run the same(ish) kernel > as guest and host. This is by design: I wanted it to be a platform > for experimentation and hacking, because I think we're still at that > stage with x86 Linux virtualization. i really really think KVM and lhype should merge, creating KVM/HVM (Hardware Virtual Machine) and KVM/LL (Linux on Linux). But that's really your business to decide, not mine :-) I guess it's not a pure technical decision :-/ ( later on KVM/LL could be extended to also run unmodified guests similar to how kqemu does it: by running guest user-space on ring 3 and letting Qemu do all of ring0 emulation. That is already leagues faster than default Qemu, and it would also nicely test lhype's cr3/pagetable management infrastructure. It can also run most 32-bit OSs out there - largely extending the userbase even on legacy hardware. ) regarding ABI: agreed that it's experimental right now and should stay so for some time, but i dont see a reason why the hypercall API that i've posted in the past few days couldnt be evolved in the way Linux syscalls evolve, by only adding to them. That doesnt really impact the flexibility of the virtualization subsystem. We could also possibly phase out older hypercalls, because the number of "applications" relying on it will be very low. Ingo ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV