<div dir="ltr">There are actually 3 we need to consider for lowest common denominator.<div><br></div><div>The one we build for, the one we build on and the one where we will run the qemu in the end.</div><div><br></div><div>I mean the core2duo is probably best match for core2-64 DEFAULT used by qemux86-64 MACHINE. But it's not good match to emulate with QEmu and KVM enabled on the host like my.</div><div><br></div><div>It's easy to work around this, we probably don't need to change the default values, but it would be good to document this case and how to override <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">QB_CPU_KVM if your host doesn't match the features of core2duo.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 26, 2018 at 1:02 AM, Martin Kelly <span dir="ltr"><<a href="mailto:mkelly@xevo.com" target="_blank">mkelly@xevo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 04/25/2018 12:54 PM, Martin Jansa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Jun 15, 2017 at 05:37:50PM +0100, Burton, Ross wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 15 June 2017 at 17:17, Martin Kelly <<a href="mailto:mkelly@xevo.com" target="_blank">mkelly@xevo.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am no expert, but running qemu -cpu help just says:<br>
<br>
kvm32 - "Common 32-bit KVM processor"<br>
kvm64 - "Common 64-bit KVM processor"<br>
<br>
My best guess is that, running on qemu without kvm, both cases will be<br>
slow (since it's all software emulation). But, using qemu -kvm, it should<br>
be fast as long as you run on a native CPU that is core2duo or better, as<br>
the native instructions can just be exposed and passed through to the host.<br>
Since core2duo is very old by now, it should be fast for virtually everyone<br>
building on x86.<br>
<br>
</blockquote>
<br>
Right, I did some digging. Assuming you have KVM enabled then in the<br>
general case the -cpu option is irrelevant as the instructions are handled<br>
natively. -cpu just changes what CPUID flags the userspace sees, and so<br>
this is the Right Thing To Do.<br>
</blockquote>
<br>
Sorry for replying to such old thread, but today I've noticed interesting side-effect of this change.<br>
<br>
Today I was checking why starting qtbase examples in qemu fails with<br>
message about missing ssse3 support which which qtbase as compiled.<br>
<br>
The DEFAULT_TUNE in qemux86-64 is indeed set to core2-64 which supports<br>
ssse3, so qtbase is right to expect it in runtime.<br>
<br>
But then I was starting qemu manually (not with runqemu) with:<br>
qemu-system-x86_64 -M q35 -smp 4 -m 4G -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -vga virtio -display sdl,gl=on -hda luneui-example-image-qemux86-6<wbr>4-20180425152329-jama.rootfs.w<wbr>ic.vmdk -enable-kvm<br>
<br>
which defaults to using this kvm64 generic CPU which doesn't support ssse3<br>
<br>
Changing it to<br>
qemu-system-x86_64 -M q35 -cpu core2duo -smp 4 -m 4G -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -vga virtio -display sdl,gl=on -hda luneui-example-image-qemux86-6<wbr>4-20180425152329-jama.rootfs.w<wbr>ic.vmdk -enable-kvm<br>
<br>
gets rid of the message from qtbase, because core2duo supports ssse3 and matches with qemux86-64,<br>
but my host CPU (AMD Bulldozer FX(tm)-8120), doesn't support the same cpu flags like core2due and qemu shows following<br>
message when starting:<br>
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:EDX.ss [bit 27]<br>
<br>
EDX.ss is Self Snoop feature which is enabled in core2duo and few other QEmu emulated CPUs, so I was looking<br>
on some other cpu I can emulate which has ssse3 while having the same flags as my host's AMD cpu<br>
<br>
e.g. -cpu phenom is relatively close, but Bulldozer CPUs don't support 3dnow, 3dnowext, so similar warning is shown.<br>
<br>
In the end I've switched to using -cpu Nehalem, which has ssse3, but doesn't enable CPUID_SS flag, now it starts without any warnings:<br>
qemu-system-x86_64 -M q35 -cpu Nehalem -smp 4 -m 4G -net nic,model=virtio -net user,hostfwd=tcp::2222-:22 -vga virtio -display sdl,gl=on -hda luneui-example-image-qemux86-6<wbr>4-20180425152329-jama.rootfs.w<wbr>ic.vmdk -enable-kvm<br>
<br>
Regards,<br>
<br>
</blockquote>
<br></div></div>
Heh, this is bringing back memories of when I wrote the patch. It's tricky to say what CPU we should pick here; we want whatever is the closest to a lowest common denominator. I don't know enough to say what the right choice is, though it is important that the CPU we build for and the one we run for are the same.<br>
<br>
Prior to this patch, we built for core2duo and then ran with kvm64, causing issues. Good follow-up work would be to see if core2duo is really the best CPU to be targeting for a lowest common denominator. If Nehalem is a better match, we might as well switch to that, as long as we switch in both build and runtime consistently.<br>
</blockquote></div><br></div>