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

[Sean Christopherson]

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@xxxxxxxxxxxx> 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.