Bug 1182650 - Can't launch any VM : rtm and hle CPU features flags needed by libvirt but not in /proc/cpuinfo
Summary: Can't launch any VM : rtm and hle CPU features flags needed by libvirt but no...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 21
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1190307 1195061 (view as bug list)
Depends On:
Blocks: 1218673
TreeView+ depends on / blocked
 
Reported: 2015-01-15 16:10 UTC by marianne@tuxette.fr
Modified: 2015-06-05 23:01 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-05 23:01:52 UTC


Attachments (Terms of Use)

Description marianne@tuxette.fr 2015-01-15 16:10:51 UTC
Description of problem:
When I try to launch a VM, it fails; logs are :

anv. 15 17:54:08 mallorne.saclay.inria.fr dbus[938]: [system] Successfully activated service 'org.freedesktop.timedate1'
janv. 15 17:54:10 mallorne.saclay.inria.fr libvirtd[2631]: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm, hle
janv. 15 17:54:10 mallorne.saclay.inria.fr org.gnome.Boxes[2013]: (gnome-boxes:2615): Boxes-WARNING **: machine.vala:576: Failed to start VM-seven 2: Unable to start domain: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: rtm, hle


Version-Release number of selected component (if applicable):
libvirt-client-1.2.9.1-2.fc21.x86_64

How reproducible:
Try to launch a VM with an Haswell processor


Actual results:
Fail

Expected results:
Work 

Additional info:
Seems related to : http://journal.siddhesh.in/posts/buggy-hle-microcode-updates-and-sigills.html
http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly

Comment 1 marianne@tuxette.fr 2015-01-15 16:23:01 UTC
Related discussion on libvirt mailing-list : 
https://www.redhat.com/archives/libvir-list/2014-December/msg00800.html (and nexts mails)

Comment 2 Daniel Berrangé 2015-01-15 16:25:17 UTC
This is really an example of libvirt working correctly. THe guest config requests a set of CPU features and the host CPU no longer provides them (thanks intel), so the guest won't start. The only real fix here is to edit the guest config to remove use of the features in question.

Comment 3 Eric Blake 2015-01-15 16:28:43 UTC
Or, if it is possible, patch qemu to emulate these features even when the host lacks them.

Comment 4 marianne@tuxette.fr 2015-01-15 16:39:24 UTC
Daniel Berrange : thanks a lot for the workaround, it's working

Comment 5 Ján Tomko 2015-02-10 10:06:51 UTC
*** Bug 1190307 has been marked as a duplicate of this bug. ***

Comment 6 Thomas Jarosch 2015-02-10 16:19:14 UTC
For the record: The same issue hit Fedora 20 after the latest microcode_ctl update, too.

Josh Boyer wrote in #1190307:
-------------------
As a bit more information, Intel pushed a firmware update that disabled the rtm/hle operations entirely because the TSX support in Haswell is broken in the chip.  It works... until it doesn't.  Fedora includes that microcode update and it is applied during early boot now.
-------------------

Comment 7 Elliott Sales de Andrade 2015-02-17 03:29:47 UTC
> The only real fix here is to edit the guest config to remove use of the features in question.

I really doubt that the people that gnome-boxes are targetting are the demographic that would be happy or comfortable with attempting this fix.

Comment 8 Elliott Sales de Andrade 2015-02-17 03:51:54 UTC
For the people wondering what "guest config" people are talking about...


Run this command to list domains (aka virtual machines, boxes, etc.):

$ virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     boxes-unknown                  shut off

If you've used gnome-boxes, it will likely be named something like the above.



To edit the config, run this command (using the names from the above command):

$ virsh edit boxes-unknown


You can then apply the change from bug 1190307, comment 1:

<cpu mode="custom" match="exact">
    <model fallback="forbid">Haswell</model>
    <feature policy='disable' name='rtm'/>
    <feature policy='disable' name='hle'/>
</cpu>

Add the two lines beginning with <feature within the <cpu></cpu> section. There may be other lines within that section, but I didn't seem to need to change them.

Comment 9 Kashyap Chamarthy 2015-02-23 10:29:30 UTC
*** Bug 1195061 has been marked as a duplicate of this bug. ***

Comment 10 Jerome Marchand 2015-03-04 15:22:10 UTC
(In reply to Thomas Jarosch from comment #6)
> For the record: The same issue hit Fedora 20 after the latest microcode_ctl
> update, too.
> 
> Josh Boyer wrote in #1190307:
> -------------------
> As a bit more information, Intel pushed a firmware update that disabled the
> rtm/hle operations entirely because the TSX support in Haswell is broken in
> the chip.  It works... until it doesn't.  Fedora includes that microcode
> update and it is applied during early boot now.
> -------------------

For those like me who were baffled by the fact that rtm and hle flags still show in cpuinfo: apparently the microcode is flashed at every boot; early in the boot process, the cpu still reports these flags.

Comment 11 Haruka Iwao 2015-04-17 01:53:13 UTC
I had the same issue and found this bug.

The upstream libvirt seems to define a new CPU model without TSX, namely Haswell-noTSX. 

http://libvirt.org/git/?p=libvirt.git;a=commit;h=c563b50605ae9895b981d198e11dbe9f6e18027b

Can we backport this to Fedora? Do we need to update the corresponding part in qemu as well?

Comment 12 Cole Robinson 2015-04-17 12:21:05 UTC
(In reply to Haruka Iwao from comment #11)
> I had the same issue and found this bug.
> 
> The upstream libvirt seems to define a new CPU model without TSX, namely
> Haswell-noTSX. 
> 
> http://libvirt.org/git/?p=libvirt.git;a=commit;
> h=c563b50605ae9895b981d198e11dbe9f6e18027b
> 
> Can we backport this to Fedora? Do we need to update the corresponding part
> in qemu as well?

I don't know if backporting that patch will actually help any affected users... just give them slightly more accurate mode=host-model behavior, which isn't that big of a deal AFAICT

jiri, does that sound right? or will the libvirt patch fix more than that?

Comment 13 Daniel Berrangé 2015-04-17 12:23:32 UTC
I think it is worth backporting, otherwise we'll have  never ending stream of bug reports about the "wrong" CPU model listed.

Comment 14 Jiri Denemark 2015-04-17 12:32:27 UTC
Right, I think we should backport this and commit 53c8062f7eb7028043a314f2f18bf34ff0e82f0d. However, the best user experience will only be achieved when the QEMU commits adding these new CPU models are backported too.

Comment 15 Haruka Iwao 2015-04-18 08:11:51 UTC
Thanks. virt-install sometimes (depending on its option) creates VM with cpu model='Haswell' not mode='host-model' so this fix would help a lot. I have filed another bug for the qemu as bug 1213053.

Comment 16 Fedora Update System 2015-04-28 16:55:05 UTC
libvirt-1.2.9.3-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/libvirt-1.2.9.3-1.fc21

Comment 17 Fedora Update System 2015-04-29 13:06:13 UTC
Package libvirt-1.2.9.3-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-1.2.9.3-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7150/libvirt-1.2.9.3-1.fc21
then log in and leave karma (feedback).


Note You need to log in before you can comment on or make changes to this bug.