GNOME Bugzilla – Bug 720798
Unable to set the correct CPU
Last modified: 2016-03-31 13:22:07 UTC
On my system, GNOME Boxes launches qemu with the following parameter: -cpu Nehalem,+rdtscp,+avx,+osxsave,+xsave,+tsc-deadline,+x2apic,+pcid,+pdcm,+xtpr,+tm2,+est,+vmx,+ds_cpl,+monitor,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme Which looks like break llvmpipe, and the GNOME Shell fails to start on a Fedora guest. When I run qemu with the '-cpu host' parameter instead, GNOME Shell starts correctly. My real CPU is an Intel Sandy Bridge Mobile processor: - Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz Package versions: spice 0.12.4 qemu 1.7.0 libvirt 1.2.0 libvirt-glib 0.1.7 libosinfo 0.2.9 spice-gtk3 0.22 gnome-boxes 3.10.2 Distribution: Arch Linux
(In reply to comment #0) > Which looks like break llvmpipe, and the GNOME Shell fails to start on a Fedora > guest. Can you be more specific about this? GNOME Shell segfaults, right? This is likely the same as https://bugzilla.redhat.com/show_bug.cgi?id=870071. It's probably a duplicate of bug #695283
It's possible, but I have a trivial question. How can I switch to a virtual terminal on the guest OS within GNOME Boxes?
I'd do that with remote-viewer
Now I see the segfaults: gnome-shell[1485] trap invalid opcode ip:7f90e357c14a sp:7ff8af67890 error:0 gnome-shell[1784] trap invalid opcode ip:7fc3ee07514a sp:7ff631fdb00 error:0 So I confirm that this bug is probably a duplicate of bug #695283. Both of us have a Sandy Bridge processor. And I opened a feature request (bug #720848) to implement VT switching within GNOME Boxes.
Created attachment 264656 [details] [review] Use the host CPU to avoid misconfiguration This patch solves the problem for me. Without this patch, 3D apps are fail to run on the guest system. E.g. glxgears throws the following error: Program received signal SIGILL, Illegal instruction.
Review of attachment 264656 [details] [review]: ::: src/vm-configurator.vala @@ +210,2 @@ var cpu = new DomainCpu (); + cpu.set_mode (DomainCpuMode.HOST_PASSTHROUGH); According to the docs, this change will make it impossible to boot the VM if CPU configuration changes: http://libvirt.org/formatdomain.html#elementsCPUAllocation . This will also imply that host is impossible to migrate to another host w/ diff CPU. Besides we really shouldn't need this change. I think this is more a bug in libvirt that it doesn't allocate the right/best CPU to VM.
(In reply to comment #6) > Review of attachment 264656 [details] [review]: > > ::: src/vm-configurator.vala > @@ +210,2 @@ > var cpu = new DomainCpu (); > + cpu.set_mode (DomainCpuMode.HOST_PASSTHROUGH); > > According to the docs, this change will make it impossible to boot the VM if > CPU configuration changes: > http://libvirt.org/formatdomain.html#elementsCPUAllocation . This will also > imply that host is impossible to migrate to another host w/ diff CPU. > I'm not sure this matters these limitations matter a lot for VMs created by Boxes, so this could be an acceptable workaround for now. > Besides we really shouldn't need this change. I think this is more a bug in > libvirt that it doesn't allocate the right/best CPU to VM. This is bug #870071
(In reply to comment #7) > (In reply to comment #6) > > Review of attachment 264656 [details] [review] [details]: > > > > ::: src/vm-configurator.vala > > @@ +210,2 @@ > > var cpu = new DomainCpu (); > > + cpu.set_mode (DomainCpuMode.HOST_PASSTHROUGH); > > > > According to the docs, this change will make it impossible to boot the VM if > > CPU configuration changes: > > http://libvirt.org/formatdomain.html#elementsCPUAllocation . This will also > > imply that host is impossible to migrate to another host w/ diff CPU. > > > > I'm not sure this matters these limitations matter a lot for VMs created by > Boxes, so this could be an acceptable workaround for now. The latter, I could agree with but not the former. People upgrading their computers or migrating existing disk to another one is a very common thing so I'm not so sure its a good idea. > > Besides we really shouldn't need this change. I think this is more a bug in > > libvirt that it doesn't allocate the right/best CPU to VM. > > This is bug #870071 Thanks for pointing it out. I'd suggest providing URL when bug is in another bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=870071 .
(In reply to comment #8) > People upgrading their computers or migrating existing disk to another one is a very common thing so I'm not so sure its a good idea. I'll start by saying I disagree on the assumption it's "very common". When that happens, if Boxes can say "saved state is invalid, drop it?", then this becomes less of an issue. And I'm not sure host-model will behave much better than host-passthrough in the scenarios you are describing. libvirt documentation for host-model is saying: "Until these issues are fixed, it's a good idea to avoid using host-model and use custom mode with just the CPU model from host capabilities XML.", this might be the way to go to solve this bug in an acceptable way for everyone..
(In reply to comment #9) > (In reply to comment #8) > > People upgrading their computers or migrating existing disk to another one is a very common thing so I'm not so sure its a good idea. > > I'll start by saying I disagree on the assumption it's "very common". Depends on your idea of "very common" I guess but based on my personal observations, I feel very safe with that assumption rather than its opposite. > When that happens, if Boxes can say "saved state is invalid, drop it?", then > this becomes less of an issue. And I'm not sure host-model will behave much > better than host-passthrough in the scenarios you are describing. Yeah, I had forgotten/misunderstood the consequences actually: https://bugzilla.redhat.com/show_bug.cgi?id=870071#c23 So I also agree that we should use the attached patch, at least as workaround.
Pushed the patch with some changes to commit log.
(In reply to comment #11) > Pushed the patch with some changes to commit log. (changing it to « Use 'host-model' CPU configuration for new VMs » was wrong as the patch changes from using 'host-model' to using 'host-passthrough')
(In reply to comment #12) > (In reply to comment #11) > > Pushed the patch with some changes to commit log. > > (changing it to « Use 'host-model' CPU configuration for new VMs » was wrong as > the patch changes from using 'host-model' to using 'host-passthrough') Oops, my bad but nothing I'll lose my sleep on.
(In reply to comment #13) > Oops, my bad but nothing I'll lose my sleep on. Not asking you to lose your sleep on it, just hoping this will be in the back of your mind next time you edit a commit log, and that you'll be extra careful.
(In reply to comment #14) > (In reply to comment #13) > > Oops, my bad but nothing I'll lose my sleep on. > > Not asking you to lose your sleep on it, just hoping this will be in the back > of your mind next time you edit a commit log, and that you'll be extra careful. It always is. Just that I can always make mistakes even if I'm super careful.
*** Bug 726882 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Created an attachment (id=264656) [details] [review] > Use the host CPU to avoid misconfiguration > > This patch solves the problem for me. > > Without this patch, 3D apps are fail to run on the guest system. E.g. glxgears > throws the following error: > > Program received signal SIGILL, Illegal instruction. Turns out we break the case of non-VT CPUs with this patch. :(
(In reply to comment #17) > (In reply to comment #5) > > Created an attachment (id=264656) [details] [review] [details] [review] > > Use the host CPU to avoid misconfiguration > > > > This patch solves the problem for me. > > > > Without this patch, 3D apps are fail to run on the guest system. E.g. glxgears > > throws the following error: > > > > Program received signal SIGILL, Illegal instruction. > > Turns out we break the case of non-VT CPUs with this patch. :( https://bugzilla.gnome.org/show_bug.cgi?id=732680