Re: which -cpu to use

[Javier Guerra Giraldez <javier@guerrag.com>]

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 guest
> like in Xen kernel? Or  paravirtual support is for device drivers only
> and has no impact on CPU handling like in Xen?
> I thought that KVM (as Xen) is a bare metal hypervisor with regards to
> giving access native access to the  CPU which have  svm or vmx support,
> and not just CPU emulation.
> I'm confused here - can someone shed some light on my ignorance on the
> matter?

you're mixing several buzzwords:

- paravirtual/fully virtualized guest: this refers as to how the guest runs in 
terms of the lowest level of hardware, mainly about accessing CPU's ring0, the 
most privileged mode of execution.  paravirtualized guests can't access ring0, 
so can't do some very low level CPU operations.  for this, the guest is 
modified to use some hypervisor calls instead of CPU operations.  since the 
guest OS has to be modified, usually the VM system doesn't bother fully 
emulating IO hardware either.  Xen works in either mode, KVM only works in 
'fully virtualized' mode, using HVM capabilities.

- paravirtualized drivers: usually paravirtualized guests (which KVM doesn't 
do) also have some special IO channels, which are faster than emulating every 
detail of an existing piece of hardware.  but even if you're fully emulating a 
CPU, there's nothing preventing you from creating special device drivers that 
know how to access the Hypervisor communication channels to do any IO needed.  
the advantage is that these drivers are easy to integrate into an oterwise-
unmodified OS.  that makes it possible to use PV drivers on windows guests, 
gaining most (if not all) performance advantages of PV guests without access 
to the guest OS's source code.

- virtio: is the IO interface presented to the guest for communicating with 
the emulator.  at least KVM uses it, but i think Xen's interface is similar.  
there are several virtio clients in current Linux kernels, so if you select 
virtio network, and block device when launching KVM, a Linux guest gets a big 
speedup.  also available if you install the PV drivers on windows guests (for 
network, block drivers aren't available yet).

- CPU type: this is only how the CPU identifies itself to the guest, and what 
capabilities it advertises.  AFAIK, it doesn't mean any software emulation (á 
la qemu), or maybe only a few non-performance-sensitive.  it's useful mainly 
to facilitate guest migration between different hosts.  if the guest OS sees 
the same CPU as the host, it might see it changing, and since all modern OSs 
check the CPU type at bootup to activate different optimised code, changing it 
while running would make it crash.  advertising only the features common to 
all hosts lets it stay constant no matter how you move the guest around.  
originally Xen supported migration only between identical hosts, but there's 
some special features to allow this on some cases. i don't know how complete 
they're currently.

hope that clears the waters a bit.

-- 
Javier