From mboxrd@z Thu Jan 1 00:00:00 1970 From: Javier Guerra Giraldez Subject: Re: which -cpu to use Date: Thu, 26 Feb 2009 07:16:53 -0500 Message-ID: <200902260716.54325.javier@guerrag.com> References: <49A5E6C6.5030907@cs.bgu.ac.il> <9EBA26E4-6C58-4983-B614-9DB6B9247620@suse.de> <49A67800.9020304@cs.bgu.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Piavlo Return-path: Received: from mail-gx0-f174.google.com ([209.85.217.174]:39872 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751984AbZBZMQl convert rfc822-to-8bit (ORCPT ); Thu, 26 Feb 2009 07:16:41 -0500 Received: by gxk22 with SMTP id 22so1245404gxk.13 for ; Thu, 26 Feb 2009 04:16:38 -0800 (PST) In-Reply-To: <49A67800.9020304@cs.bgu.ac.il> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: Piavlo wrote: > Alexander Graf wrote: > > virtio drivers have nothing to do with CPU. > > Yes I mistakenly used the term "viritio drivers" instead of > "paravirtual guest support". So what I wanted to ask is if I build a > guest kernel with paravitual support > will it make the native hardware cpu features available inside the gu= est > like in Xen kernel? Or paravirtual support is for device drivers onl= y > and has no impact on CPU handling like in Xen? > I thought that KVM (as Xen) is a bare metal hypervisor with regards t= o > giving access native access to the CPU which have svm or vmx suppor= t, > and not just CPU emulation. > I'm confused here - can someone shed some light on my ignorance on th= e > matter? you're mixing several buzzwords: - paravirtual/fully virtualized guest: this refers as to how the guest = runs in=20 terms of the lowest level of hardware, mainly about accessing CPU's rin= g0, the=20 most privileged mode of execution. paravirtualized guests can't access= ring0,=20 so can't do some very low level CPU operations. for this, the guest is= =20 modified to use some hypervisor calls instead of CPU operations. since= the=20 guest OS has to be modified, usually the VM system doesn't bother fully= =20 emulating IO hardware either. Xen works in either mode, KVM only works= in=20 'fully virtualized' mode, using HVM capabilities. - paravirtualized drivers: usually paravirtualized guests (which KVM do= esn't=20 do) also have some special IO channels, which are faster than emulating= every=20 detail of an existing piece of hardware. but even if you're fully emul= ating a=20 CPU, there's nothing preventing you from creating special device driver= s that=20 know how to access the Hypervisor communication channels to do any IO n= eeded. =20 the advantage is that these drivers are easy to integrate into an oterw= ise- unmodified OS. that makes it possible to use PV drivers on windows gue= sts,=20 gaining most (if not all) performance advantages of PV guests without a= ccess=20 to the guest OS's source code. - virtio: is the IO interface presented to the guest for communicating = with=20 the emulator. at least KVM uses it, but i think Xen's interface is sim= ilar. =20 there are several virtio clients in current Linux kernels, so if you se= lect=20 virtio network, and block device when launching KVM, a Linux guest gets= a big=20 speedup. also available if you install the PV drivers on windows guest= s (for=20 network, block drivers aren't available yet). - CPU type: this is only how the CPU identifies itself to the guest, an= d what=20 capabilities it advertises. AFAIK, it doesn't mean any software emulat= ion (=C3=A1=20 la qemu), or maybe only a few non-performance-sensitive. it's useful m= ainly=20 to facilitate guest migration between different hosts. if the guest OS= sees=20 the same CPU as the host, it might see it changing, and since all moder= n OSs=20 check the CPU type at bootup to activate different optimised code, chan= ging it=20 while running would make it crash. advertising only the features commo= n to=20 all hosts lets it stay constant no matter how you move the guest around= =2E =20 originally Xen supported migration only between identical hosts, but th= ere's=20 some special features to allow this on some cases. i don't know how com= plete=20 they're currently. hope that clears the waters a bit. --=20 Javier