lkml.org 
[lkml]   [2020]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configured
    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.

    \
     
     \ /
      Last update: 2020-02-26 01:43    [W:2.143 / U:1.708 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site