On Monday, June 29, 2020 5:49pm, "Sean Christopherson" <sean.j.christopher...@intel.com> said:
> On Mon, Jun 29, 2020 at 02:22:45PM -0700, Andy Lutomirski wrote: >> >> >> > On Jun 29, 2020, at 1:54 PM, David P. Reed <dpr...@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. > Thanks. If no one else responds with additional suggestions, I will make it into 3 patches. I'm happy to learn the nuances of the kernel patch regimen.
