From mboxrd@z Thu Jan 1 00:00:00 1970 From: Piavlo Subject: Re: which -cpu to use Date: Thu, 26 Feb 2009 14:57:16 +0200 Message-ID: <49A691AC.7030508@cs.bgu.ac.il> References: <49A5E6C6.5030907@cs.bgu.ac.il> <9EBA26E4-6C58-4983-B614-9DB6B9247620@suse.de> <49A67800.9020304@cs.bgu.ac.il> <200902260716.54325.javier@guerrag.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Javier Guerra Giraldez Return-path: Received: from indigo.cs.bgu.ac.il ([132.72.42.23]:57545 "EHLO indigo.cs.bgu.ac.il" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751763AbZBZM5X (ORCPT ); Thu, 26 Feb 2009 07:57:23 -0500 In-Reply-To: <200902260716.54325.javier@guerrag.com> Sender: kvm-owner@vger.kernel.org List-ID: Hi Javier, thanks for the explanations - they make things much clear to me. Still I have one more misunderstanding - please see below. Javier Guerra Giraldez wrote: > you're mixing several buzzwords: > > - paravirtual/fully virtualized guest: this refers as to how the gues= t runs in=20 > terms of the lowest level of hardware, mainly about accessing CPU's r= ing0, the=20 > most privileged mode of execution. paravirtualized guests can't acce= ss 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. sin= ce the=20 > guest OS has to be modified, usually the VM system doesn't bother ful= ly=20 > emulating IO hardware either. Xen works in either mode, KVM only wor= ks in=20 > 'fully virtualized' mode, using HVM capabilities. > > - paravirtualized drivers: usually paravirtualized guests (which KVM = doesn't=20 > do) also have some special IO channels, which are faster than emulati= ng every=20 > detail of an existing piece of hardware. but even if you're fully em= ulating a=20 > CPU, there's nothing preventing you from creating special device driv= ers that=20 > know how to access the Hypervisor communication channels to do any IO= needed. =20 > the advantage is that these drivers are easy to integrate into an ote= rwise- > unmodified OS. What is still unclear to me is that's the actual difference between PV drivers implementation in paravirtual linux guest and PV dirvers in HVM linux guest? AFAIK in xen guest the P= V front-end drivers are quite simple, and in KVM guest to use PV drivers the guest linux needs to be compiled with paravirtual guest and viritio drivers support. So in both cases the OS is modified = - but there is the actual difference? Thanks Alex > that makes it possible to use PV drivers on windows guests, > gaining most (if not all) performance advantages of PV guests without= access=20 > to the guest OS's source code. > > - virtio: is the IO interface presented to the guest for communicatin= g with=20 > the emulator. at least KVM uses it, but i think Xen's interface is s= imilar. =20 > there are several virtio clients in current Linux kernels, so if you = select=20 > virtio network, and block device when launching KVM, a Linux guest ge= ts a big=20 > speedup. also available if you install the PV drivers on windows gue= sts (for=20 > network, block drivers aren't available yet). > > - CPU type: this is only how the CPU identifies itself to the guest, = and what=20 > capabilities it advertises. AFAIK, it doesn't mean any software emul= ation (=C3=A1=20 > la qemu), or maybe only a few non-performance-sensitive. it's useful= mainly=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 mod= ern OSs=20 > check the CPU type at bootup to activate different optimised code, ch= anging it=20 > while running would make it crash. advertising only the features com= mon to=20 > all hosts lets it stay constant no matter how you move the guest arou= nd. =20 > originally Xen supported migration only between identical hosts, but = there's=20 > some special features to allow this on some cases. i don't know how c= omplete=20 > they're currently. > > hope that clears the waters a bit. > > =20