You are not logged in.
There are already 4 out of around 14 steps of the bisect procedure which I have completed. Unfortunately, I have a limited time budget and it seems that I have to recreate the configuration and recompile everything after each step. Thus, it might still take some time until I find the guilty commit. Isn't anyone else doing a bisect?
Offline
The last 5 steps compiled very fast, thus I was able to finish the bisecting procedure today.
As R00KIE said, the following commit is the guilty one:
The one that looks interesting is this one "KVM: VMX: require virtual NMI support", the full commit message as follows:
commit 2c82878b0cb38fd516fd612c67852a6bbf282003
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon Mar 27 14:37:28 2017 +0200KVM: VMX: require virtual NMI support
Virtual NMIs are only missing in Prescott and Yonah chips. Both are obsolete
for virtualization usage---Yonah is 32-bit only even---so drop vNMI emulation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>But I'm not sure this affects the cpu you are using.
I contacted the kernel developers to find out whether it is intended that this patch also affects Conroe chips.
Offline
HI
After doing a roolback to 2017-07-25 and re-upgrading my system with the latest versions of pacakages everything works again. Except that I have not applied the latest versions of the kernel:
Core / linux 4.11.9-1 -> 4.12.4-1
Core / linux-headers 4.11.9-1 -> 4.12.4-1
I tried to redo the update with the kernel versions update, but I have the same errors again
Libvirtd [428]: 2017-08-06 10: 24: 18.054 + 0000: 467: error: qemuConnectGetDomainCapabilities: 19033: invalid argument: KVM is not supported by '/usr/sbin/qemu-system-x86_64' on this host
Libvirtd [428]: 2017-08-06 10: 24: 45.754 + 0000: 466: error: qemuProcessStartValidate: 4619: unsupported configuration: Domain requires KVM, but it is not available. BIOS, and host configuration is setup to load the kvm modules
Offline
The current state is like this (summarized from the thread I linked above):
There are two steppings of Conroe chips, an older one that misses support like vNMI and one that supports it. Since major changes regarding the hypervisor in the linux kernel were done, supporting KVM on these older chips seems to be a lot of work. For reference (that there are more people affected) I mentioned this thread. Let's see what the future brings!
Offline
Would upstream consider reverting the change for the 4.12.y stable series if not for 4.13+?
Edit:
That would gain you 3 to 4 weeks until 4.13 is released plus however long the 4.13 release is kept in testing.
Last edited by loqs (2017-08-07 18:58:18)
Offline
As far as I understood, the patches can't easily be reverted. I think everything comes down to whether upstream decides on continuing support for these chips or not. To gain more time, currently I think the best approach would be using linux-lts instead.
Offline
$ git checkout v4.12.5
HEAD is now at 45100eec5f68... Linux 4.12.5
$ git revert -n 2c82878b0cb38fd516fd612c67852a6bbf282003
The commit reverts cleanly according to git no further testing carried out.
Offline
Oh, I didn't try it myself. Is there anyone that really needs a 4.12 kernel and can't use a 4.9 (linux-lts)? If upstream decides against supporting the chip anymore, we will have the same problems in 3 to 4 weeks again. Thus, I'm actually against giving the kernel devs more work like reverting this patch until we know what is planned for the future.
Offline
$ git checkout v4.12.5 HEAD is now at 45100eec5f68... Linux 4.12.5 $ git revert -n 2c82878b0cb38fd516fd612c67852a6bbf282003
The commit reverts cleanly according to git no further testing carried out.
For now yes and as a stop-gap measure it is fine, but in the future things will assume that vNMI is supported and I'm sure there will be mysterious breakage if this is not dealt with upstream and people keep reverting this change.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I'm not (yet) competent to work with bisect and do the job you do
So, waiting for a future kernel version that will take support of this processor is not a problem for me. I will test the next versions to see if the problem is solved
Thank you very much for your time and help.
Offline
So, waiting for a future kernel version that will take support of this processor is not a problem for me.
Given the rarity of your machine I'm currently leaning towards _not_
reverting the change.
So there is currently no plan for such a future kernel Sadar.
Offline
Yes, I understand, but I would be surprised that this is not supported in the future because there are still users with this configuration
At worst, if necessary, I will change if he knows that the support is assured on Debian for example. Linux allows this facility: change the distro and resume the configurations easily ... ;-))
Offline
I'd say that if distros don't specifically revert this change (and they might not because they would have to deal with the fallout) then eventually no distro will support this, your best bet here is to convince upstream to revert this change, either fully or partially.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
If I understand correctly, if there are many people who have the same problem with the same processor there may be a patch.
If not, I should stay in version 4.11.x or change hardware. I do not know how to recompile the kernel myself by including the code for the support of these processors.
Offline
If not switch to the linux-lts kernel which is currently based on the 4.9 series and to which the patch removing support has not currently been backported.
Assuming it is not backported to 4.9 lts you should be able to keep kvm support until the first half of 2018 when linux-lts will switch to 4.14 which is scheduled to be next lts kernel.
At that point you would then need to make your own 4.9 series kernel to keep kvm support for your hardware or use a kernel package that is outdated and may have exploitable vulnerabilities.
Offline
Given the rarity of your machine I'm currently leaning towards _not_
reverting the change.
I have the same issue, my CPU is a Intel(R) Core(TM)2 T7200 @ 2.00GHz
I guess it is not as rare as Paolo Bonzini think it is.
@Rachus
Could you please send him a reply at the LKML that several users are affected?
Offline
I already mentioned this thread but got no response. Maybe the best way would be, if you inform him about this issue yourself.
Offline
I have the same issue! I have 4 servers that looses from it !!
https://bbs.archlinux.org/viewtopic.php … 0#p1744810
It's very, very bad news!
About what's thinks developers??
Offline
As a small note: KVM support for older Core 2 CPUs is probably reintroduced in kernel 4.15. As soon as it reaches the Arch repositories, I will try it out. Until then, I am going to keep on using linux-lts as suggested by loqs and ua4000.
Offline
Just installed Linux 4.15.1 and can confirm that KVM is working properly on my Conroe CPU.
Offline