Hi guys,
I justed tested kernel 5.2.1-rc1 which contains the following commit
reverting the previously mentionned commit but... the problem is still
there:
[root@wolfe linux-stable]# su - jenkins -s /bin/bash
[jenkins@wolfe ~]$ ssh root@192.168.122.2
Activate the web console with: systemctl enable --now cockpit.socket
Last login: Tue May 21 08:53:28 2019 from 192.168.122.1
[root@undercloud-0-rhosp15 ~]# modprobe kvm_intel
modprobe: ERROR: could not insert 'kvm_intel': Input/output error
[root@undercloud-0-rhosp15 ~]# logout
Connection to 192.168.122.2 closed.
[jenkins@wolfe ~]$ uname -a
Linux wolfe.orion 5.2.0-20190521081919+ #6 SMP Tue May 21 08:25:14 EDT
2019 x86_64 x86_64 x86_64 GNU/Linux
I'll try reverting the commit and then reverting only the commit that
causes issues.
commit f93f7ede087f2edcc18e4b02310df5749a6b5a61
Author: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
Date: Wed May 8 09:08:19 2019 -0700
Revert "KVM: nVMX: Expose RDPMC-exiting only when guest supports PMU"
The RDPMC-exiting control is dependent on the existence of the RDPMC
instruction itself, i.e. is not tied to the "Architectural Performance
Monitoring" feature. For all intents and purposes, the control exists
on all CPUs with VMX support since RDPMC also exists on all VCPUs with
VMX supported. Per Intel's SDM:
The RDPMC instruction was introduced into the IA-32 Architecture in
the Pentium Pro processor and the Pentium processor with MMX
technology.
The earlier Pentium processors have performance-monitoring
counters, but
they must be read with the RDMSR instruction.
Because RDPMC-exiting always exists, KVM requires the control and
refuses
to load if it's not available. As a result, hiding the PMU from a
guest
breaks nested virtualization if the guest attemts to use KVM.
While it's not explicitly stated in the RDPMC pseudocode, the VM-Exit
check for RDPMC-exiting follows standard fault vs. VM-Exit
prioritization
for privileged instructions, e.g. occurs after the CPL/CR0.PE/CR4.PCE
checks, but before the counter referenced in ECX is checked for
validity.
In other words, the original KVM behavior of injecting a #GP was
correct,
and the KVM unit test needs to be adjusted accordingly, e.g. eat
the #GP
when the unit test guest (L3 in this case) executes RDPMC without
RDPMC-exiting set in the unit test host (L2).
This reverts commit e51bfdb68725dc052d16241ace40ea3140f938aa.
Fixes: e51bfdb68725 ("KVM: nVMX: Expose RDPMC-exiting only when
guest supports PMU")
Reported-by: David Hill <hilld@xxxxxxxxxxxxxxx>
Cc: Saar Amar <saaramar@xxxxxxxxxxxxx>
Cc: Mihai Carabas <mihai.carabas@xxxxxxxxxx>
Cc: Jim Mattson <jmattson@xxxxxxxxxx>
Cc: Liran Alon <liran.alon@xxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
On 2019-05-08 6:14 p.m., bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=203543
--- Comment #8 from Liran Alon (liran.alon@xxxxxxxxxx) ---
+Paolo
What are your thoughts on this?
What is the reason that KVM relies on CPU_BASED_RDPMC_EXITING to be exposed
from underlying CPU? How is it critical for it’s functionality?
If it’s because we want to make sure that we hide host PMCs, we should
condition this to be a min requirement of kvm_intel only in case underlying CPU
exposes PMU to begin with.
Do you agree? If yes, I can create the patch to fix this.
-Liran
On 8 May 2019, at 16:51, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote:
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D203543&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=7TirfLMNxYI-3Ygxm3kjDUB49Jwmk8bqD7671wy0hi8&s=Z_L1UqH19zon0ohDrCMU91ixA-Wn_vO7d-fO8s2G3PI&e=
--- Comment #5 from David Hill (hilld@xxxxxxxxxxxxxxx) ---
I can confirm that reverting that commit solves the problem:
e51bfdb68725 ("KVM: nVMX: Expose RDPMC-exiting only when guest supports PMU”)
--
You are receiving this mail because:
You are watching the assignee of the bug.
