Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp900198ybg; Wed, 10 Jun 2020 17:18:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBC9fXGzTN1cIZkDC6eqX4BPhb0/TsuaCw1OuC1/qLZuIyaiBw6NjHc6tjFzvB3JM7CFCN X-Received: by 2002:a17:906:2c07:: with SMTP id e7mr5798833ejh.172.1591834717243; Wed, 10 Jun 2020 17:18:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591834717; cv=none; d=google.com; s=arc-20160816; b=dN6TxcAjxaJVFtknCngfCRzL/b7B4C7OrJ86jF5YEk6WDTZ5hI4DnKJIJI2I6Nh2o6 PJo1J6XqylcQzZJcsg2A7i/m4GK4Gl6idzv2MLaGcrOmzjBTxZviy6dUBqLm58rga+lk 8udUU6pVOvZ78xvugOlF19EUkJvaHesJmqRMRw6nX8WQltf1eK3JneKPolW/SgBG/NUj 7b+LRJUb9Kg9w1MLoliUD0ra6pjFfjIFTiSKuOJMgnm8HV70D0Z9OMPtG5FhkkBhG8H2 1eLhaTQ8P2DxeTUpCsqCQx3vdmDb/Q19Ic3fcqox5Ehnedtak6bN4a2ZoSfQTsgWLpLc J0DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=iHao7Jxny3P3ePcrYrjLcQVBYuxeL3mVp0j7FnnS+Bs=; b=xkoKwS3MFfp+44dQFmyPAlchxQdM+RbSajFLD+JzL71h9aOvG4HjA9nuscBXhz3WID ZXRMH3QZYlQsgvyAzaiXYRXvC1fp2GQHvwSzTMx09gY6O8NhtTmSBjc2fL1f/V9oIO9M tu15V67q1OeX5LhveGR0xnRhJyyHoCHPmdpD/I80k/XFZVOn/A3p6JYXuesfWjEiv8U9 YU8hECgm0084kPpeZ9Ouek5Z13eu2yT9rsCYKY30dK4U9kOGOqjmCTdHt1HL7uCSxK8F LtquD62cwi0Xtw1h/JVwJOoRM5bpduFK8ESqGcxTF2DrBUmV+Li8n+4xDUDw/RfD302h EIfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=u6mHIj8t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t13si690750edj.100.2020.06.10.17.18.14; Wed, 10 Jun 2020 17:18:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=u6mHIj8t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726912AbgFKAPt (ORCPT + 99 others); Wed, 10 Jun 2020 20:15:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726820AbgFKAPs (ORCPT ); Wed, 10 Jun 2020 20:15:48 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35FF4C08C5C1 for ; Wed, 10 Jun 2020 17:15:47 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id x14so4280867wrp.2 for ; Wed, 10 Jun 2020 17:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iHao7Jxny3P3ePcrYrjLcQVBYuxeL3mVp0j7FnnS+Bs=; b=u6mHIj8tc2pymYIfKG6eytsU9EfJO732bDOW9rllhAVzlVaqRnIRhUt0y3hseFrwqM 9AyGgd00NsFD/f3FzcRAOOKUtzSSub0+NcNNSWHaaij7CjsqTyJbYxp4AIWfSRydnYH1 rpBZvYzR9JZUMZTs1ft6t6WLmQOjhkdOTiirmrlC7rxMH2yqWw9jqZehJeWM9wFmxtbj RCA2wiDBTGVT32Iljf7ZVQxHy6q0sfHkJRD6BJCSyDFJ9xjAX5Rak30fJF9sRIjGuLku lCBR5c0DLQe4fFwsYVQkoXjpF9K1WNz6MHCMGKNd87G1RRsE5WdCRjRjZlm48SgR+i25 U/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iHao7Jxny3P3ePcrYrjLcQVBYuxeL3mVp0j7FnnS+Bs=; b=dH1ibdDhLcCFZx0H8/qK7pKmP7afGaluBW7vHMWL0x/8bi+zYlYl7J0yBt49TTEIKH PEnlts+3n1CVP52aU+cdv/kzHt4U76gA8mFCzab4FKsdQ5yGQesVhaHU3Bkils7QAaqQ Eu0+vyN+u3J1RgIjey7nAN/Z0KTLShx1TZmtNOPAoLMaOTPQNReYW2n248K433ZV8JnI f0OKb1Lrc1TDy+Z0/8VKfSIT4vgDnrO6Mxk/Dh6Op6KqzIKCO+BJ/FauJv/UOnKeaB4d 4okGjSkZDDuCv+XgQRfXZqv8YIqQxsKNbVSXvuBqELnKVzB8nmNNaU7VGQa3+BBcIhUH eLfg== X-Gm-Message-State: AOAM5304ew+JWrIfdbTkw1o+mVy44o/9BG6WfybcVExvaV+tdQGVuVnV 0JDAqAHPaq6Q4v+lOVQostaqHLL8YcfcIGGKt8yYRnQK X-Received: by 2002:adf:82f8:: with SMTP id 111mr6301223wrc.257.1591834546119; Wed, 10 Jun 2020 17:15:46 -0700 (PDT) MIME-Version: 1.0 References: <20200610181254.2142-1-dpreed@deepplum.com> <3F5CEF02-0561-4E28-851B-8E993F76DC9B@amacapital.net> <20200611000032.GI18790@linux.intel.com> In-Reply-To: <20200611000032.GI18790@linux.intel.com> From: Andy Lutomirski Date: Wed, 10 Jun 2020 17:15:34 -0700 Message-ID: Subject: Re: [PATCH] Fix undefined operation VMXOFF during reboot and crash To: Sean Christopherson Cc: "David P. Reed" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "H. Peter Anvin" , Allison Randal , Enrico Weigelt , Greg Kroah-Hartman , Kate Stewart , "Peter Zijlstra (Intel)" , Randy Dunlap , Martin Molnar , Andy Lutomirski , Alexandre Chartre , Jann Horn , Dave Hansen , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 10, 2020 at 5:00 PM Sean Christopherson wrote: > > On Wed, Jun 10, 2020 at 02:59:19PM -0700, Andy Lutomirski wrote: > > > > > > > On Jun 10, 2020, at 11:21 AM, David P. Reed wro= te: > > > > > > =EF=BB=BFIf a panic/reboot occurs when CR4 has VMX enabled, a VMXOFF = is > > > done on all CPUS, to allow the INIT IPI to function, since > > > INIT is suppressed when CPUs are in VMX root operation. > > > However, VMXOFF causes an undefined operation fault if the CPU is not > > > in VMX operation, that is, VMXON has not been executed, or VMXOFF > > > has been executed, but VMX is enabled. > > > > I=E2=80=99m surprised. Wouldn=E2=80=99t this mean that emergency reboot= s always fail it a VM > > is running? I would think someone would have noticed before. > > The call to cpu_vmxoff() is conditioned on CR4.VMXE=3D=3D1, which KVM tog= gles in > tandem with VMXON and VMXOFF. Out of tree hypervisors presumably do the > same. That's obviously not atomic though, e.g. VMXOFF will #UD if the > vmxoff_nmi() NMI arrives between CR4.VMXE=3D1 and VMXON, or between VMXOF= F > and CR4.VMXE=3D0. It would be nice for the commit message to say "this happens when nmxoff_nmi() races with KVM's VMXON/VMXOFF toggling". Or the commit message should say something else if the bug happens for a different reason. The race with KVM should be quite unusual, since it involves rebooting concurrently with loading or unloading KVM.