I have been doing some reading about optimising QEMU and one thing that I am confused about is the
At the moment I am using
-cpu host which is supposed to transfer all the hosts cpu features to the guest, but some say that it does more than that and gives the guests extra features the host may not support. This leads to software emulation of the features which could slow down the VM.
Another article (http://forum.ipfire.org/viewtopic.php?t=12642) says to use the
qemu32 cpu option, and then append all additional processor specific options that the host supports to it.
Which method actually optimizes the virtual processor better? And is there specific flags that the
qemu32 processor already implements that I do not have to manually include or should I include every flag from
/proc/cpuinfo? Likewise should I be using the qemu32 virtual processor if I am running a 64bit guest?
Thanks for any help.
First, I would not believe everything you read on the Internet. Most of it is crap.
Though, it seems that
-cpu host does indeed behave in the way you describe. At least, a note on qemu’s wiki states that they intend it to behave that way.
all-you-can-enable: Enable every single bit that can be enabled, including the ones not present on the host but that can be emulated.
-cpu host will be the “all-you-can-enable” mode, that will enable every bit from GET_SUPPORTED_CPUID on the VCPU
They also note that if you want more control over the CPU model, that libvirt is the way to go.
And, second, outside of very rare circumstances I would never attempt to run qemu directly myself. Rather, it’s best to use libvirt (as recommended) and one of its front ends such as virsh or virt-manager, as these give you complete control over the virtual machine with a much easier to use interface (in the case of virt-manager).
In particular, libvirt is capable of doing what you want: copying the host CPU features to the guest exactly, without enabling features that don’t exist and must be emulated (using
host-passthrough, though most of the time
host-model is sufficient).
As for qemu32, qemu’s default is qemu64, so I don’t see what you could possibly gain, except perhaps a migraine, by changing this to qemu32.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.