lkml.org 
[lkml]   [2020]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] KVM: x86/mmu: Add capability to zap only sptes for the affected memslot
On Thu, 9 Jul 2020 21:29:22 -0700
Sean Christopherson <sean.j.christopherson@intel.com> wrote:

> +Alex, whom I completely spaced on Cc'ing.
>
> Alex, this is related to the dreaded VFIO memslot zapping issue from last
> year. Start of thread: https://patchwork.kernel.org/patch/11640719/.
>
> The TL;DR of below: can you try the attached patch with your reproducer
> from the original bug[*]? I honestly don't know whether it has a legitimate
> chance of working, but it's the one thing in all of this that I know was
> definitely a bug. I'd like to test it out if only to sate my curiosity.
> Absolutely no rush.

Mixed results, maybe you can provide some guidance. Running this
against v5.8-rc4, I haven't reproduced the glitch. But it's been a
long time since I tested this previously, so I went back to v5.3-rc5 to
make sure I still have a recipe to trigger it. I can still get the
failure there as the selective flush commit was reverted in rc6. Then
I wondered, can I take broken v5.3-rc5 and apply this fix to prove that
it works? No, v5.3-rc5 + this patch still glitches. So I thought
maybe I could make v5.8-rc4 break by s/true/false/ in this patch.
Nope. Then I applied the original patch from[1] to try to break it.
Nope. So if anything, I think the evidence suggests this was broken
elsewhere and is now fixed, or maybe it is a timing issue that I can't
trigger on newer kernels. If the reproducer wasn't so touchy and time
consuming, I'd try to bisect, but I don't have that sort of bandwidth.
Thanks,

Alex

[1] https://patchwork.kernel.org/patch/10798453/

\
 
 \ /
  Last update: 2020-07-13 20:23    [W:0.068 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site