Re: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configured

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 25, 2020 at 01:49:13PM -0800, Jacob Keller wrote:
> I recently ran into a general protection fault that I believe is the
> fault of this patch:
> 
> > [   32.189584] general protection fault, maybe for address 0xffffb567801bcf58: 0000 [#1] SMP PTI
> > [   32.198103] CPU: 1 PID: 2600 Comm: rngd Not tainted 5.6.0-rc2-jk+ #2
> > [   32.204454] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
> > [   32.214887] RIP: 0010:hardware_enable+0x100/0x1a0 [kvm_intel]
> > [   32.220628] Code: <f3> 0f c7 34 24 31 c0 80 3d 59 8d 03 00 00 75 36 48 8b 5c 24 10 65
> > [   32.239373] RSP: 0000:ffffb567801bcf58 EFLAGS: 00010002
> > [   32.244598] RAX: 0000000000300000 RBX: 0000000000000086 RCX: ffff8f2650440000
> > [   32.251730] RDX: 0000000000300000 RSI: 0000000000000000 RDI: ffff8f2650457020
> > [   32.258862] RBP: 0000000000000007 R08: 000000077ea5d531 R09: 0000000000000000
> > [   32.265986] R10: 000001432bf20982 R11: 0000000000000000 R12: ffffd55b80467110
> > [   32.273118] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > [   32.280243] FS:  00007facfe66f700(0000) GS:ffff8f2650440000(0000) knlGS:0000000000000000
> > [   32.288329] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [   32.294077] CR2: 00007facf0003000 CR3: 0000000b7d402006 CR4: 00000000007626e0
> > [   32.301210] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [   32.308342] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [   32.315474] PKRU: 55555554
> > [   32.318186] Call Trace:
> > [   32.320642]  <IRQ>
> > [   32.322689]  kvm_arch_hardware_enable+0x84/0x240 [kvm]
> > [   32.327836]  hardware_enable_nolock+0x31/0x60 [kvm]
> > [   32.332717]  flush_smp_call_function_queue+0x4d/0xe0
> > [   32.337683]  smp_call_function_interrupt+0x3a/0xd0
> > [   32.342471]  call_function_interrupt+0xf/0x20
> > [   32.346830]  </IRQ>
> > [   32.498314] ---[ end trace bfeeeba337a01208 ]---
> 
> I noticed that a slightly older commit from before this does not fail.
> Additionally, the system reports the following during boot:
> 
> kvm: disabled by bios

One other thing that's been bothering me; you mention in a later email that
this bug resulting in a crash during boot.  The low timestamps also suggest
the system is fairly early in its bringup.

But KVM only does VMXON when it actually creates a VM[*].  During boot I
would expect the bug to result in KVM being incorrectly loaded/enabled, but
that alone wouldn't trigger a crash.

I assume/hope your system is automatically running some form of virt
process at boot?  Not that there's anything wrong with that, it's just
suprising and I want to make sure there's not something really funky going
on.

[*] KVM also does VMXON when hotplugging a CPU, but only if KVM has active
    VMs, and the IPI callback above indicates this isn't the hotplug case.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux