From: Alex Williamson <alex.williamson@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiong Zhang <xiong.y.zhang@intel.com>,
Wayne Boyer <wayne.boyer@intel.com>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH] KVM: x86/mmu: Add capability to zap only sptes for the affected memslot
Date: Mon, 13 Jul 2020 12:22:26 -0600 [thread overview]
Message-ID: <20200713122226.28188f93@x1.home> (raw)
In-Reply-To: <20200710042922.GA24919@linux.intel.com>
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/
next prev parent reply other threads:[~2020-07-13 18:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 2:50 [PATCH] KVM: x86/mmu: Add capability to zap only sptes for the affected memslot Sean Christopherson
2020-07-08 16:08 ` Paolo Bonzini
2020-07-09 21:12 ` Sean Christopherson
2020-07-09 22:18 ` Paolo Bonzini
2020-07-10 4:29 ` Sean Christopherson
2020-07-13 18:22 ` Alex Williamson [this message]
2020-07-13 19:06 ` Sean Christopherson
2020-07-21 3:03 ` Sean Christopherson
2020-07-21 16:00 ` Alex Williamson
2020-07-23 15:57 ` Sean Christopherson
2020-07-23 18:35 ` Alex Williamson
2020-09-14 16:49 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200713122226.28188f93@x1.home \
--to=alex.williamson@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=wayne.boyer@intel.com \
--cc=xiong.y.zhang@intel.com \
--cc=zhenyuw@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).