Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1704697 > unrolled thread

kvm_intel fails to load on Conroe CPUs running Linux 4.12

Started by"Sebastian Rachuj" <Rachus@web.de>
First post2017-08-05 21:30 +0200
Last post2017-08-08 23:50 +0200
Articles 9 — 5 participants

Back to article view | Back to linux.kernel

Contents

  kvm_intel fails to load on Conroe CPUs running Linux 4.12 "Sebastian Rachuj" <Rachus@web.de> - 2017-08-05 21:30 +0200
    Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Paolo Bonzini <pbonzini@redhat.com> - 2017-08-06 23:20 +0200
      Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Sebastian Rachuj <rachus@web.de> - 2017-08-06 23:30 +0200
        Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Paolo Bonzini <pbonzini@redhat.com> - 2017-08-07 11:50 +0200
          Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Nadav Amit <nadav.amit@gmail.com> - 2017-08-07 19:20 +0200
          Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Sebastian Rachuj <rachus@web.de> - 2017-08-07 19:20 +0200
            Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Paolo Bonzini <pbonzini@redhat.com> - 2017-08-07 20:00 +0200
              Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Sebastian Rachuj <rachus@web.de> - 2017-08-07 20:50 +0200
              Re: Re: kvm_intel fails to load on Conroe CPUs running Linux 4.12 Niall Walsh <lkml@celtux.org> - 2017-08-08 23:50 +0200

#1704697 — kvm_intel fails to load on Conroe CPUs running Linux 4.12

From"Sebastian Rachuj" <Rachus@web.de>
Date2017-08-05 21:30 +0200
Subjectkvm_intel fails to load on Conroe CPUs running Linux 4.12
Message-ID<ubcVQ-DP-17@gated-at.bofh.it>
Dear linux developers,

since my upgrade from linux 4.11 to linux 4.12 the "kvm_intel" module does not load correctly anymore. "Modprobing" the kernel module gives an Input/Output error. It seems to be related to the CPU architecture and (to my knowledge) affects Conroe CPUs. I did a bisect and found the following commit as the guilty one:

commit 2c82878b0cb38fd516fd612c67852a6bbf282003
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Mon Mar 27 14:37:28 2017 +0200

    KVM: 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>

Since the commit message only mentions Prescott and Yonah chips, I wanted to ask whether this commit is also intended to affect Conroe CPUs (which are probably still a bit more widespread). Do you see a solution to bring back support for Conroe chips?

Thank you for your hard work on the kernel!

Best regards,
Sebastian Rachuj

[toc] | [next] | [standalone]

#1704973

FromPaolo Bonzini <pbonzini@redhat.com>
Date2017-08-06 23:20 +0200
Message-ID<ubB7P-7pO-15@gated-at.bofh.it>
In reply to#1704697
On 05/08/2017 21:26, Sebastian Rachuj wrote:
> Dear linux developers,
> 
> since my upgrade from linux 4.11 to linux 4.12 the "kvm_intel" module
> does not load correctly anymore. "Modprobing" the kernel module gives an
> Input/Output error. It seems to be related to the CPU architecture and
> (to my knowledge) affects Conroe CPUs. I did a bisect and found the
> following commit as the guilty one:

What is your cpuinfo?  I tested on a Conroe Xeon X3220 (family 6,
model 15, stepping 11) when I posted that patch, and it did have virtual
NMIs.

Paolo

[toc] | [prev] | [next] | [standalone]

#1704982

FromSebastian Rachuj <rachus@web.de>
Date2017-08-06 23:30 +0200
Message-ID<ubBhw-7tc-29@gated-at.bofh.it>
In reply to#1704973
On 06.08.2017 23:10, Paolo Bonzini wrote:
> On 05/08/2017 21:26, Sebastian Rachuj wrote:
>> Dear linux developers,
>>
>> since my upgrade from linux 4.11 to linux 4.12 the "kvm_intel" module
>> does not load correctly anymore. "Modprobing" the kernel module gives an
>> Input/Output error. It seems to be related to the CPU architecture and
>> (to my knowledge) affects Conroe CPUs. I did a bisect and found the
>> following commit as the guilty one:
> 
> What is your cpuinfo?  I tested on a Conroe Xeon X3220 (family 6,
> model 15, stepping 11) when I posted that patch, and it did have virtual
> NMIs.

Thank you for looking into the issue. My cpuinfo is as follows:

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz
stepping	: 6
microcode	: 0xc6
cpu MHz		: 2128.000
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni 
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm 
tpr_shadow dtherm
bugs		:
bogomips	: 4275.23
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 15
model name	: Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz
stepping	: 6
microcode	: 0xc6
cpu MHz		: 2128.000
cache size	: 4096 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni 
dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm 
tpr_shadow dtherm
bugs		:
bogomips	: 4275.05
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

[toc] | [prev] | [next] | [standalone]

#1705302

FromPaolo Bonzini <pbonzini@redhat.com>
Date2017-08-07 11:50 +0200
Message-ID<ubMPD-6vW-7@gated-at.bofh.it>
In reply to#1704982

[Multipart message — attachments visible in raw view] — view raw

On 06/08/2017 23:23, Sebastian Rachuj wrote:
> On 06.08.2017 23:10, Paolo Bonzini wrote:
>> On 05/08/2017 21:26, Sebastian Rachuj wrote:
>>> Dear linux developers,
>>>
>>> since my upgrade from linux 4.11 to linux 4.12 the "kvm_intel" module
>>> does not load correctly anymore. "Modprobing" the kernel module gives an
>>> Input/Output error. It seems to be related to the CPU architecture and
>>> (to my knowledge) affects Conroe CPUs. I did a bisect and found the
>>> following commit as the guilty one:
>>
>> What is your cpuinfo?  I tested on a Conroe Xeon X3220 (family 6,
>> model 15, stepping 11) when I posted that patch, and it did have virtual
>> NMIs.
> 
> Thank you for looking into the issue. My cpuinfo is as follows:

Looks like Intel was already differentiating virtualization features
across SKUs.  Please run the attached script as root to see what other
things are different (apparently) between non-Xeon and Xeon Conroes.

Thanks,

Paolo

> $ cat /proc/cpuinfo
> processor    : 0
> vendor_id    : GenuineIntel
> cpu family    : 6
> model        : 15
> model name    : Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz
> stepping    : 6
> microcode    : 0xc6
> cpu MHz        : 2128.000
> cache size    : 4096 KB
> physical id    : 0
> siblings    : 2
> core id        : 0
> cpu cores    : 2
> apicid        : 0
> initial apicid    : 0
> fpu        : yes
> fpu_exception    : yes
> cpuid level    : 10
> wp        : yes
> flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
> nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf
> pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm
> tpr_shadow dtherm
> bugs        :
> bogomips    : 4275.23
> clflush size    : 64
> cache_alignment    : 64
> address sizes    : 36 bits physical, 48 bits virtual
> power management:
> 
> processor    : 1
> vendor_id    : GenuineIntel
> cpu family    : 6
> model        : 15
> model name    : Intel(R) Core(TM)2 CPU          6420  @ 2.13GHz
> stepping    : 6
> microcode    : 0xc6
> cpu MHz        : 2128.000
> cache size    : 4096 KB
> physical id    : 0
> siblings    : 2
> core id        : 1
> cpu cores    : 2
> apicid        : 1
> initial apicid    : 1
> fpu        : yes
> fpu_exception    : yes
> cpuid level    : 10
> wp        : yes
> flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
> nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf
> pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm
> tpr_shadow dtherm
> bugs        :
> bogomips    : 4275.05
> clflush size    : 64
> cache_alignment    : 64
> address sizes    : 36 bits physical, 48 bits virtual
> power management:

[toc] | [prev] | [next] | [standalone]

#1705724

FromNadav Amit <nadav.amit@gmail.com>
Date2017-08-07 19:20 +0200
Message-ID<ubTR7-3eW-7@gated-at.bofh.it>
In reply to#1705302
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 06/08/2017 23:23, Sebastian Rachuj wrote:
>> On 06.08.2017 23:10, Paolo Bonzini wrote:
>>> On 05/08/2017 21:26, Sebastian Rachuj wrote:
>>>> Dear linux developers,
>>>> 
>>>> since my upgrade from linux 4.11 to linux 4.12 the "kvm_intel" module
>>>> does not load correctly anymore. "Modprobing" the kernel module gives an
>>>> Input/Output error. It seems to be related to the CPU architecture and
>>>> (to my knowledge) affects Conroe CPUs. I did a bisect and found the
>>>> following commit as the guilty one:
>>> 
>>> What is your cpuinfo?  I tested on a Conroe Xeon X3220 (family 6,
>>> model 15, stepping 11) when I posted that patch, and it did have virtual
>>> NMIs.
>> 
>> Thank you for looking into the issue. My cpuinfo is as follows:
> 
> Looks like Intel was already differentiating virtualization features
> across SKUs.  Please run the attached script as root to see what other
> things are different (apparently) between non-Xeon and Xeon Conroes.

There may be another explanation. If I remember correctly from my days in
Intel, Intel initially sold CMWA (Conroe) B-step. The next step, E-step,
introduced a couple of new features, which may have included vNMI.

The CPU of Sebastian appears to be B1 according to cpuinfo.

Nadav

[toc] | [prev] | [next] | [standalone]

#1705726

FromSebastian Rachuj <rachus@web.de>
Date2017-08-07 19:20 +0200
Message-ID<ubTR7-3eW-9@gated-at.bofh.it>
In reply to#1705302
On 07.08.2017 11:43, Paolo Bonzini wrote:
> On 06/08/2017 23:23, Sebastian Rachuj wrote:
>> On 06.08.2017 23:10, Paolo Bonzini wrote:
>>> On 05/08/2017 21:26, Sebastian Rachuj wrote:
>>>> Dear linux developers,
>>>>
>>>> since my upgrade from linux 4.11 to linux 4.12 the "kvm_intel" module
>>>> does not load correctly anymore. "Modprobing" the kernel module gives an
>>>> Input/Output error. It seems to be related to the CPU architecture and
>>>> (to my knowledge) affects Conroe CPUs. I did a bisect and found the
>>>> following commit as the guilty one:
>>>
>>> What is your cpuinfo?  I tested on a Conroe Xeon X3220 (family 6,
>>> model 15, stepping 11) when I posted that patch, and it did have virtual
>>> NMIs.
>>
>> Thank you for looking into the issue. My cpuinfo is as follows:
> 
> Looks like Intel was already differentiating virtualization features
> across SKUs.  Please run the attached script as root to see what other
> things are different (apparently) between non-Xeon and Xeon Conroes.

Here you are, I hope it helps:

# python vmxcap
Basic VMX Information
   Hex: 0x1a040000000007
   Revision                                 7
   VMCS size                                1024
   VMCS restricted to 32 bit addresses      no
   Dual-monitor support                     yes
   VMCS memory type                         6
   INS/OUTS instruction information         no
   IA32_VMX_TRUE_*_CTLS support             no
pin-based controls
   External interrupt exiting               yes
   NMI exiting                              yes
   Virtual NMIs                             no
   Activate VMX-preemption timer            no
   Process posted interrupts                no
primary processor-based controls
   Interrupt window exiting                 yes
   Use TSC offsetting                       yes
   HLT exiting                              yes
   INVLPG exiting                           yes
   MWAIT exiting                            yes
   RDPMC exiting                            yes
   RDTSC exiting                            yes
   CR3-load exiting                         forced
   CR3-store exiting                        forced
   CR8-load exiting                         yes
   CR8-store exiting                        yes
   Use TPR shadow                           yes
   NMI-window exiting                       no
   MOV-DR exiting                           yes
   Unconditional I/O exiting                yes
   Use I/O bitmaps                          yes
   Monitor trap flag                        no
   Use MSR bitmaps                          yes
   MONITOR exiting                          yes
   PAUSE exiting                            yes
   Activate secondary control               no
secondary processor-based controls
   Virtualize APIC accesses                 no
   Enable EPT                               no
   Descriptor-table exiting                 no
   Enable RDTSCP                            no
   Virtualize x2APIC mode                   no
   Enable VPID                              no
   WBINVD exiting                           no
   Unrestricted guest                       no
   APIC register emulation                  no
   Virtual interrupt delivery               no
   PAUSE-loop exiting                       no
   RDRAND exiting                           no
   Enable INVPCID                           no
   Enable VM functions                      no
   VMCS shadowing                           no
   Enable ENCLS exiting                     no
   RDSEED exiting                           no
   Enable PML                               no
   EPT-violation #VE                        no
   Conceal non-root operation from PT       no
   Enable XSAVES/XRSTORS                    no
   Mode-based execute control (XS/XU)       no
   TSC scaling                              no
VM-Exit controls
   Save debug controls                      forced
   Host address-space size                  yes
   Load IA32_PERF_GLOBAL_CTRL               no
   Acknowledge interrupt on exit            yes
   Save IA32_PAT                            no
   Load IA32_PAT                            no
   Save IA32_EFER                           no
   Load IA32_EFER                           no
   Save VMX-preemption timer value          no
   Clear IA32_BNDCFGS                       no
   Conceal VM exits from PT                 no
VM-Entry controls
   Load debug controls                      forced
   IA-32e mode guest                        yes
   Entry to SMM                             yes
   Deactivate dual-monitor treatment        yes
   Load IA32_PERF_GLOBAL_CTRL               no
   Load IA32_PAT                            no
   Load IA32_EFER                           no
   Load IA32_BNDCFGS                        no
   Conceal VM entries from PT               no
Miscellaneous data
   Hex: 0x403c0
   VMX-preemption timer scale (log2)        0
   Store EFER.LMA into IA-32e mode guest control no
   HLT activity state                       yes
   Shutdown activity state                  yes
   Wait-for-SIPI activity state             yes
   IA32_SMBASE support                      no
   Number of CR3-target values              4
   MSR-load/store count recommendation      0
   IA32_SMM_MONITOR_CTL[2] can be set to 1  no
   VMWRITE to VM-exit information fields    no
   Inject event with insn length=0          no
   MSEG revision identifier                 0
VPID and EPT capabilities
   Hex: 0x0
   Execute-only EPT translations            no
   Page-walk length 4                       no
   Paging-structure memory type UC          no
   Paging-structure memory type WB          no
   2MB EPT pages                            no
   1GB EPT pages                            no
   INVEPT supported                         no
   EPT accessed and dirty flags             no
   Single-context INVEPT                    no
   All-context INVEPT                       no
   INVVPID supported                        no
   Individual-address INVVPID               no
   Single-context INVVPID                   no
   All-context INVVPID                      no
   Single-context-retaining-globals INVVPID no
VM Functions
   Hex: 0x0
   EPTP Switching                           no

[toc] | [prev] | [next] | [standalone]

#1705761

FromPaolo Bonzini <pbonzini@redhat.com>
Date2017-08-07 20:00 +0200
Message-ID<ubUtP-3uU-1@gated-at.bofh.it>
In reply to#1705726
On 07/08/2017 19:17, Sebastian Rachuj wrote:
>>>
>>> Thank you for looking into the issue. My cpuinfo is as follows:
>>
>> Looks like Intel was already differentiating virtualization features
>> across SKUs.  Please run the attached script as root to see what other
>> things are different (apparently) between non-Xeon and Xeon Conroes.
> 
> Here you are, I hope it helps:

Not much to say, unfortunately.  It's pretty much the same capabilities
as a Prescott/Cedar Mill processor, except that it has MSR bitmaps.  It
also lacks FlexPriority compared to the Conroe I had checked.

It's not great that even the revert patch doesn't apply cleanly---this
is *not* necessarily a boring area of the hypervisor...

Given the rarity of your machine I'm currently leaning towards _not_
reverting the change.  I'll check another non-Xeon Core 2 tomorrow that
is from December 2008 (IIRC).  If that one also lacks vNMI, or if I get
other reports, I suppose I will have to reconsider that.

Paolo

[toc] | [prev] | [next] | [standalone]

#1705802

FromSebastian Rachuj <rachus@web.de>
Date2017-08-07 20:50 +0200
Message-ID<ubVge-45a-17@gated-at.bofh.it>
In reply to#1705761
On 07.08.2017 19:50, Paolo Bonzini wrote:
> On 07/08/2017 19:17, Sebastian Rachuj wrote:
>>>>
>>>> Thank you for looking into the issue. My cpuinfo is as follows:
>>>
>>> Looks like Intel was already differentiating virtualization features
>>> across SKUs.  Please run the attached script as root to see what other
>>> things are different (apparently) between non-Xeon and Xeon Conroes.
>>
>> Here you are, I hope it helps:
> 
> Not much to say, unfortunately.  It's pretty much the same capabilities
> as a Prescott/Cedar Mill processor, except that it has MSR bitmaps.  It
> also lacks FlexPriority compared to the Conroe I had checked.
> 
> It's not great that even the revert patch doesn't apply cleanly---this
> is *not* necessarily a boring area of the hypervisor...
> 
> Given the rarity of your machine I'm currently leaning towards _not_
> reverting the change.  I'll check another non-Xeon Core 2 tomorrow that
> is from December 2008 (IIRC).  If that one also lacks vNMI, or if I get
> other reports, I suppose I will have to reconsider that.

That's unfortunate to hear. Just for completeness, I want to mention a 
thread in the Archlinux forum, I created, where two other people (Sadar 
and losko) also complained about not working KVM [1]. Additionally, 
Linux 4.12 has not reached yet reached distributions with a greater 
amount of users.

If supporting these chips is too much of a hassle, I will probably have 
to buy a new CPU to enjoy KVM support with a current linux kernel.

Anyway, thanks again for figuring this out!


[1]: https://bbs.archlinux.org/viewtopic.php?id=228645

[toc] | [prev] | [next] | [standalone]

#1706897

FromNiall Walsh <lkml@celtux.org>
Date2017-08-08 23:50 +0200
Message-ID<uckxY-60T-11@gated-at.bofh.it>
In reply to#1705761

[Multipart message — attachments visible in raw view] — view raw

Hi,

On 07/08/17 18:50, Paolo Bonzini wrote:
> Given the rarity of your machine I'm currently leaning towards _not_
> reverting the change.  I'll check another non-Xeon Core 2 tomorrow that
> is from December 2008 (IIRC).  If that one also lacks vNMI, or if I get
> other reports, I suppose I will have to reconsider that.

afraid I've the same issue with 4.12, kvm_intel doesn't load and won't 
(but does on 4.11) on my Dell XPS M1210 with a Core 2 Duo T7200 from 
April 2007.

cpuinfo and vmxcap output attached

Thanks,

Niall

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web