Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
Thread-Topic: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether MSR
 IA32_FEAT_CTL is configured
Thread-Index: AQHVt7m4HwSK3U3TVkGmKj0nXJjnJqgs22KAgAHb2oCAACKiQA==
Date:   Thu, 27 Feb 2020 04:20:52 +0000
Message-ID: <MWHPR1101MB2157609E21AD5BC5D9E8897AF7EB0@MWHPR1101MB2157.namprd11.prod.outlook.com>
References: <20191221044513.21680-14-sean.j.christopherson@intel.com>
 <e741196d-52aa-0f5e-8f1e-a37ddf2e5025@intel.com>
 <20200227021221.GA14478@linux.intel.com>
In-Reply-To: <20200227021221.GA14478@linux.intel.com>
Accept-Language: en-NZ, en-US
Content-Language: en-US
dlp-version: 11.2.0.6
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: be41532d-d38e-46be-a85f-08d7bb3c6ea2
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 04:20:52.3000
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aRWlIqVhZUMK/Mo9aixjkFilq/SfbyGIRnwq8gdHbYpMca62j9PVsj9p5Kb0wnDRhl3uf6proSGM+5Uh+yNZzw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2285
X-OriginatorOrg: intel.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Subject: Re: [PATCH v5 13/19] x86/cpufeatures: Add flag to track whether =
MSR
> IA32_FEAT_CTL is configured
>=20
> 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, BI=
OS
> 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 3=
6 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
>=20
> One other thing that's been bothering me; you mention in a later email th=
at this
> bug resulting in a crash during boot.  The low timestamps also suggest th=
e
> system is fairly early in its bringup.
>=20
> 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, b=
ut
> that alone wouldn't trigger a crash.
>=20
> I assume/hope your system is automatically running some form of virt proc=
ess
> 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 ma=
y 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
>=20
> [*] KVM also does VMXON when hotplugging a CPU, but only if KVM has activ=
e
>     VMs, and the IPI callback above indicates this isn't the hotplug case=
.