On Tue, Feb 25, 2020 at 03:54:34PM -0800, Jacob Keller wrote:
On 2/25/2020 3:29 PM, Sean Christopherson wrote:
On Tue, Feb 25, 2020 at 02:52:32PM -0800, Jacob Keller wrote:
On 2/25/2020 2:12 PM, Sean Christopherson wrote:
On Tue, Feb 25, 2020 at 01:49:13PM -0800, Jacob Keller wrote:
Hi Sean,
I suspect something is wrong and the features are enabled even though the BIOS has it disabled, leading to later failure because of this.
Hrm. On the failing kernel, what are the values of MSR 0x3a for all CPUs, i.e. what's the output of 'sudo rdmsr -a 0x3a'?
On the old (fedora 30) kernel, every cpu reports as '1'.
I can't easily test the failing kernel because it crashes during boot.
No need, your BIOS is likely locking the MSR, I doubt the value is any different when running the new kernel.
Does reverting commit a4d0b2fdbcf7 ("KVM: VMX: Use VMX feature flag to query BIOS enabling") resolve the issue?
Is the failing kernel an (umodified) upstream kernel? A stable kernel? Or something else? Assuming it's an unmodified upstream kernel, can you send your .config? I've tried all the obvious Kconfig combinations but haven't been able to reproduce the problem. Staring at the code hasn't yielded any revelations either.
I reverted the suggested commit and added some prints:
[ 26.056398] X86_FEATURE_MSR_IA32_FEAT_CTL is enabled [ 26.062426] X86_FEATURE_VMX is enabled [ 26.066923] kvm: disabled by bios
So the old code flow is finding KVM to be disabled, but both features are set...
The code that sets this is run first:
Feb 25 15:46:05 jbrandeb-saw1 kernel: x86/cpu: FEAT_CTL_LOCKED is set Feb 25 15:46:05 jbrandeb-saw1 kernel: x86/cpu: FEAT_CTL_VMX_ENABLED_INSIDE_SMX is unset Feb 25 15:46:05 jbrandeb-saw1 kernel: x86/cpu: FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX is unset Feb 25 15:46:05 jbrandeb-saw1 kernel: x86/cpu: MSR locked by bios Feb 25 15:46:05 jbrandeb-saw1 kernel: x86/cpu: VMX (outside TXT) disabled by BIOS Feb 25 15:46:05 jbrandeb-saw1 kernel: x86/cpu: disabling X86_FEATURE_VMX
But somehow... it is still set later...
So there's something weird going on. Maybe "boot_cpu_has" in the vmx_disabled_by_bios is wrong? Hmm.
Hmm, perhaps a bug somewhere else is overwriting the cpufeatures bit for X86_FEATURE_VMX. Let me see if I can reproduce from net-next.