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.
