From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Paravirt KVM capabilities Date: Wed, 10 Jan 2007 12:43:17 +0200 Message-ID: <45A4C345.5050404@qumranet.com> References: <20070109141916.GA13276@vlad.carfax.org.uk> <45A3A642.1030604@qumranet.com> <1168384852.19646.161.camel@localhost.localdomain> <20070110094750.GA934@elte.hu> <45A4BB74.9010102@redhat.com> <20070110101839.GA6444@elte.hu> 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: Ingo Molnar In-Reply-To: <20070110101839.GA6444-X9Un+BFzKDI@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 Ingo Molnar wrote: > * Ulrich Drepper wrote: > > >> Ingo Molnar wrote: >> >>> i really really think KVM and lhype should merge, creating KVM/HVM >>> (Hardware Virtual Machine) and KVM/LL (Linux on Linux). >>> >> This is only sufficient if either KVM with paravirt Linux kernels has >> no performance penalty or lhype becomes able to execute paravirt Linux >> kernels. >> > > yes, both would be the goal i think. Single kernel image can run as a > KVM host, as a KVM/HVM guest [if CPU support] or as a KVM/LL guest [if > no CPU support]. There's no hypercall overhead on native kernels, we > have binary-patching infrastructure in place to turn them into NOPs. > (which makes it quite close to zero-cost) > > right now the KVM paravirtualization work we are doing is gradually > transitioning KVM/HVM towards KVM/LL in essence, by eliminating all VM > exit reasons from KVM/HVM and turning them into hypercalls. Once that > has been achieved, KVM/LL could be implemented by an extra ll.c module > in drivers/kvm/, which does the cr3 tricks and pagetable maintainance > and CPU state save/restore, fault/trap/irq passback (and not much else). > > So i see very nice short and long term synergy between native Linux, > KVM/HVM guests and KVM/LL guests. What is an hypercall-accelerated > driver under KVM/HVM is a paravirtual driver on KVM/LL. What is a > hypercall-based speedup for KVM/HVM is a paravirtual facility for > KVM/LL. One and the same thing serves both purposes. > > If you have a CONFIG_PARAVIRT guest, I believe it will always be faster to run it without hardware assisted virtualization: - you cannot eliminate vmexits due to host interrupts - a hypercall will (probably) keep being more expensive than a syscall; it simply has a lot more work to do - cr3 switches for CONFIG_PARAVIRT syscalls (which are necessary on x86_64) will probably become very cheap with tagged tlbs So, in my opinion, CONFIG_PARAVIRT on non-hvm will eventually win on pure performance. Hardware assisted virtualization will be used where you wish to run unmodified guests, and where ABI stability is critical. I won't mind being proved wrong, though. And of course we should share drivers and APIs between the two technologies. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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