From: "Huang, Kai" <kai.huang@intel.com>
To: "Christopherson, Sean J" <sean.j.christopherson@intel.com>,
"Keller, Jacob E" <jacob.e.keller@intel.com>
Cc: "TonyWWang-oc@zhaoxin.com" <TonyWWang-oc@zhaoxin.com>,
"acme@kernel.org" <acme@kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"bp@alien8.de" <bp@alien8.de>, "bp@suse.de" <bp@suse.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"jacob.jun.pan@linux.intel.com" <jacob.jun.pan@linux.intel.com>,
"jarkko.sakkinen@linux.intel.com"
<jarkko.sakkinen@linux.intel.com>,
"jmattson@google.com" <jmattson@google.com>,
"jolsa@redhat.com" <jolsa@redhat.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
"shuah@kernel.org" <shuah@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"Luck, Tony" <tony.luck@intel.com>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"wanpengli@tencent.com" <wanpengli@tencent.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: RE: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configured
Date: Thu, 27 Feb 2020 04:20:52 +0000 [thread overview]
Message-ID: <MWHPR1101MB2157609E21AD5BC5D9E8897AF7EB0@MWHPR1101MB2157.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20200227021221.GA14478@linux.intel.com>
> 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.
next prev parent reply other threads:[~2020-02-27 4:21 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-21 4:44 [PATCH v5 00/19] x86/cpu: Clean up handling of VMX features Sean Christopherson
2019-12-21 4:44 ` [PATCH v5 01/19] x86/msr-index: Clean up bit defines for IA32_FEATURE_CONTROL MSR Sean Christopherson
2019-12-21 4:44 ` [PATCH v5 02/19] selftests: kvm: Replace manual MSR defs with common msr-index.h Sean Christopherson
2019-12-21 4:44 ` [PATCH v5 03/19] tools arch x86: Sync msr-index.h from kernel sources Sean Christopherson
2019-12-21 4:44 ` [PATCH v5 04/19] x86/intel: Initialize IA32_FEAT_CTL MSR at boot Sean Christopherson
2019-12-21 4:44 ` [PATCH v5 05/19] x86/mce: WARN once if IA32_FEAT_CTL MSR is left unlocked Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 06/19] x86/centaur: Use common IA32_FEAT_CTL MSR initialization Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 07/19] x86/zhaoxin: " Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 08/19] x86/cpu: Clear VMX feature flag if VMX is not fully enabled Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 09/19] x86/vmx: Introduce VMX_FEATURES_* Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 10/19] x86/cpu: Detect VMX features on Intel, Centaur and Zhaoxin CPUs Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 11/19] x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_* Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 12/19] x86/cpu: Set synthetic VMX cpufeatures during init_ia32_feat_ctl() Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR IA32_FEAT_CTL is configured Sean Christopherson
2020-02-25 21:49 ` Jacob Keller
2020-02-25 22:12 ` Sean Christopherson
2020-02-25 22:52 ` Jacob Keller
2020-02-25 23:29 ` Sean Christopherson
2020-02-25 23:54 ` Jacob Keller
2020-02-26 0:41 ` Jacob Keller
2020-02-26 0:42 ` Sean Christopherson
2020-02-26 0:58 ` Jacob Keller
2020-02-26 20:41 ` Jacob Keller
2020-02-26 20:57 ` Sean Christopherson
2020-02-26 21:03 ` Jacob Keller
2020-02-26 21:25 ` Sean Christopherson
2020-02-26 21:53 ` Jacob Keller
2020-02-27 2:12 ` Sean Christopherson
2020-02-27 4:20 ` Huang, Kai [this message]
2020-02-27 18:09 ` Jacob Keller
2019-12-21 4:45 ` [PATCH v5 14/19] KVM: VMX: Drop initialization of IA32_FEAT_CTL MSR Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 15/19] KVM: VMX: Use VMX feature flag to query BIOS enabling Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 16/19] KVM: VMX: Check for full VMX support when verifying CPU compatibility Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 17/19] KVM: VMX: Use VMX_FEATURE_* flags to define VMCS control bits Sean Christopherson
2020-01-13 18:32 ` Borislav Petkov
2020-01-13 18:37 ` Sean Christopherson
2020-01-13 18:38 ` Borislav Petkov
2020-01-13 18:42 ` Sean Christopherson
2020-01-13 18:52 ` [PATCH] KVM: VMX: Rename define to CPU_BASED_USE_TSC_OFFSETTING Borislav Petkov
2020-01-13 20:16 ` Sean Christopherson
2020-01-14 9:31 ` Borislav Petkov
2020-01-14 17:27 ` Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 18/19] perf/x86: Provide stubs of KVM helpers for non-Intel CPUs Sean Christopherson
2019-12-21 4:45 ` [PATCH v5 19/19] KVM: VMX: Allow KVM_INTEL when building for Centaur and/or Zhaoxin CPUs Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MWHPR1101MB2157609E21AD5BC5D9E8897AF7EB0@MWHPR1101MB2157.namprd11.prod.outlook.com \
--to=kai.huang@intel.com \
--cc=TonyWWang-oc@zhaoxin.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=jacob.e.keller@intel.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jmattson@google.com \
--cc=jolsa@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).