Re: [PATCH v2] Fix undefined operation VMXOFF during reboot and crash

From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "David P. Reed" <dpreed@deepplum.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Allison Randal <allison@lohutok.net>,
	Enrico Weigelt <info@metux.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Martin Molnar <martin.molnar.programming@gmail.com>,
	Andy Lutomirski <luto@kernel.org>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	Jann Horn <jannh@google.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] Fix undefined operation VMXOFF during reboot and crash
Date: Mon, 29 Jun 2020 14:49:56 -0700	[thread overview]
Message-ID: <20200629214956.GA12962@linux.intel.com> (raw)
In-Reply-To: <0AFABBBA-18B7-4E2F-BCE7-D69889CC0F79@amacapital.net>

On Mon, Jun 29, 2020 at 02:22:45PM -0700, Andy Lutomirski wrote:
> 
> 
> > On Jun 29, 2020, at 1:54 PM, David P. Reed <dpreed@deepplum.com> wrote:
> > 
> > Simple question for those on the To: and CC: list here. Should I
> > abandon any hope of this patch being accepted? It's been a long time.
> > 
> > The non-response after I acknowledged that this was discovered by when
> > working on a personal, non-commercial research project - which is
> > "out-of-tree" (apparently dirty words on LKML) has me thinking my
> > contribution is unwanted. That's fine, I suppose. I can maintain this patch
> > out-of-tree as well.  I did incorporate all the helpful suggestions I
> > received in this second patch, and given some encouragement, will happily
> > submit a revised v3 if there is any likelihood of acceptance. I'm wary of
> > doing more radical changes (like combining emergency and normal paths).
> > 
> 
> Sorry about being slow and less actively encouraging than we should be. We
> absolutely welcome personal contributions. The actual problem is that
> everyone is worked and we’re all slow. Also, you may be hitting a corner case
> in the process: is this a KVM patch or an x86 patch?

It's an x86 patch as it's not KVM specific, e.g. this code also helps play
nice with out of tree hypervisors.

The code change is mostly good, but it needs to be split up as there are
three separate fixes:

  1. Handle #UD on VMXON due to a race.
  2. Mark memory and flags as clobbered by VMXON.
  3. Change emergency_vmx_disable_all() to not manually check cpu_vmx_enabled().

Yes, the changes are tiny, but if for example #3 introduces a bug then we
don't have to revert #1 and #2.  Or perhaps older kernels are only subject
to the #1 and #2 and thus dumping all three changes into a single patch makes
it all harder to backport.  In other words, all the usual "one change per
patch" reasons.