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

[Huang, Kai]

> Subject: Re: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR
> IA32_FEAT_CTL is configured
> 
> 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.

I can be wrong but it appears during boot (before you can login) libvirt may create VM simply to call some qemu monitor APIs to get some info. The VM is then destroyed after libvirt gets that info of course.

Thanks,
-Kai
> 
> [*] 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.