which -cpu to use

which -cpu to use

[Piavlo]

 Hi,

 I'm new to KVM and have some questions regarding kvm cpu emulation, 
hope you can answer them.

I have a kvm node with Dual-Core AMD Opteron(tm) Processor 2218 processors.

1)I was wondering choosing what cpu emulation for VM  would give best 
performance?

I get the following options
# kvm -cpu ?
x86           qemu64
x86           phenom
x86         core2duo
x86           qemu32
x86          coreduo
x86              486
x86          pentium
x86         pentium2
x86         pentium3
x86           athlon
x86             n270
#

I was thinking one of qemu64/phenom/athlon .
Does It matter what 64bit cpu emulation i choose?
What would be chosen if I omit the -cpu option?

2) I want to optimize/recompile a gentoo VM system packages for the 
chosen cpu - if that matters.
Does rebuilding the VM packages to fine tuned for the emulated cpu give 
any advantages?

3) Do I have to boot a VM kernel with guest viritio drivers, to get a 
not emulated real cpu access - like I have in Xen?

 Thanks a lot.
 Alex

Re: which -cpu to use

[Alexander Graf]

On 26.02.2009, at 01:48, Piavlo wrote:

> Hi,
>
> I'm new to KVM and have some questions regarding kvm cpu emulation,  
> hope you can answer them.
>
> I have a kvm node with Dual-Core AMD Opteron(tm) Processor 2218  
> processors.
>
> 1)I was wondering choosing what cpu emulation for VM  would give  
> best performance?
>
> I get the following options
> # kvm -cpu ?
> x86           qemu64
> x86           phenom
> x86         core2duo
> x86           qemu32
> x86          coreduo
> x86              486
> x86          pentium
> x86         pentium2
> x86         pentium3
> x86           athlon
> x86             n270
> #
>
> I was thinking one of qemu64/phenom/athlon .
> Does It matter what 64bit cpu emulation i choose?
> What would be chosen if I omit the -cpu option?

If you omit -cpu it chooses the "qemu64" model, which is the best  
choice for most cases. Don't choose anything else if you don't have  
any specific reason to do so.

> 2) I want to optimize/recompile a gentoo VM system packages for the  
> chosen cpu - if that matters.
> Does rebuilding the VM packages to fine tuned for the emulated cpu  
> give any advantages?

I don't think features like SSE3 matter that much in a normal  
environment. You won't get too much more benefit from choosing a  
different CPU type.

> 3) Do I have to boot a VM kernel with guest viritio drivers, to get  
> a not emulated real cpu access - like I have in Xen?

virtio drivers have nothing to do with CPU. They are about devices  
like network and block. If you want to have PV drivers for those, you  
need to have a kernel that supports virtio (incl. virtio_pci) and  
specify that you want to use virtio on the qemu command line as  
options to -net or -drive.

Alex

Re: which -cpu to use

[Piavlo]

Alexander Graf wrote:
>> 2) I want to optimize/recompile a gentoo VM system packages for the
>> chosen cpu - if that matters.
>> Does rebuilding the VM packages to fine tuned for the emulated cpu
>> give any advantages?
>
> I don't think features like SSE3 matter that much in a normal environment.
 I just wanted to rebuild the guest with following basic CGLAGS
"-march=opteron -O2 -pipe" (no sse3 and like features) tuned for my
hardware node cpu.
In Xen then i use guest linux VM both in fully virtualized mode and
paravirtual mode I see in guest's /proc/cpuinfo  the same
naitive cpu model as in hardware  node (while of course some feature
flags like svm,sse3 are missing) - but I can build the guests
with cpu native gcc -march support anyway. While seeing emulated cpu 
model in /proc/cpuinfo
 model name      : QEMU Virtual CPU version 0.9.1
is confusing and i'm not sure if i can use -march=opteron here?
> You won't get too much more benefit from choosing a different CPU type.
>> 3) Do I have to boot a VM kernel with guest viritio drivers, to get a
>> not emulated real cpu access - like I have in Xen?
>
> 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?

 Thanks
 Alex
> They are about devices like network and block. If you want to have PV
> drivers for those, you need to have a kernel that supports virtio
> (incl. virtio_pci) and specify that you want to use virtio on the qemu
> command line as options to -net or -drive.
>
> Alex

Re: which -cpu to use

[Alexander Graf]

On 26.02.2009, at 12:07, Piavlo wrote:

> Alexander Graf wrote:
>>> 2) I want to optimize/recompile a gentoo VM system packages for the
>>> chosen cpu - if that matters.
>>> Does rebuilding the VM packages to fine tuned for the emulated cpu
>>> give any advantages?
>>
>> I don't think features like SSE3 matter that much in a normal  
>> environment.
> I just wanted to rebuild the guest with following basic CGLAGS
> "-march=opteron -O2 -pipe" (no sse3 and like features) tuned for my
> hardware node cpu.
> In Xen then i use guest linux VM both in fully virtualized mode and
> paravirtual mode I see in guest's /proc/cpuinfo  the same
> naitive cpu model as in hardware  node (while of course some feature
> flags like svm,sse3 are missing) - but I can build the guests
> with cpu native gcc -march support anyway. While seeing emulated cpu
> model in /proc/cpuinfo
> model name      : QEMU Virtual CPU version 0.9.1
> is confusing and i'm not sure if i can use -march=opteron here?

You can still use all the optimizations you want. -cpu only modifies  
the CPUID flags exposed to the guest, not the features supported by  
the CPU. So if your CPU supports say SSE3 and you can't find "pni" in / 
proc/cpuinfo in the guest, it still works.

>
>> You won't get too much more benefit from choosing a different CPU  
>> type.
>>> 3) Do I have to boot a VM kernel with guest viritio drivers, to  
>>> get a
>>> not emulated real cpu access - like I have in Xen?
>>
>> 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?

The features are there, you just don't see them in /proc/cpuinfo.  
Paravirt support is completely unrelated to that.

Alex

Re: which -cpu to use

[Javier Guerra Giraldez]

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

Re: which -cpu to use

[Piavlo]

 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 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.
 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 PV
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 
> 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.
>
>   

Re: which -cpu to use

[Javier Guerra]

On Thu, Feb 26, 2009 at 7:57 AM, Piavlo <piavka@cs.bgu.ac.il> wrote:
>  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 PV
> 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?

first of all, using paravirtual drivers isn't considered 'core' OS
modification.  usually they're compiled in the Linux kernel, but could
be loaded as modules.  and in Windows case, they're always loaded
modules.  PV guests OTOH, is a very (very) inner-core modification
(but a conceptually simple one, the requirements used to be documented
in a single HTML for early Xen systems)

now, in KVM (and possibly HVM Xen) the virtio drivers are presented
via a special PCI device, while on fully PV guests, there's some
function calls that can be used to communicate with the hypervisor.
so, there might be some very low-level differences, but above that,
they should be the same.  as for performance, i really don't think it
makes any perceptible difference.


-- 
Javier

Re: which -cpu to use

[paolo pedaletti]

Ciao Javier Guerra Giraldez,

> you're mixing several buzzwords:

thank you for this clear explanation.

-- 
Paolo Pedaletti