From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: 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: Fri, 10 Jul 2020 00:18:17 +0200 [thread overview]
Message-ID: <49c7907a-3ab4-b5db-ccb4-190b990c8be3@redhat.com> (raw)
In-Reply-To: <20200709211253.GW24919@linux.intel.com>
On 09/07/20 23:12, Sean Christopherson wrote:
>> It's bad that we have no clue what's causing the bad behavior, but I
>> don't think it's wise to have a bug that is known to happen when you
>> enable the capability. :/
(Note that this wasn't a NACK, though subtly so).
> I don't necessarily disagree, but at the same time it's entirely possible
> it's a Qemu bug.
No, it cannot be. QEMU is not doing anything but
KVM_SET_USER_MEMORY_REGION, and it's doing that synchronously with
writes to the PCI configuration space BARs.
> Even if this is a kernel bug, I'm fairly confident at this point that it's
> not a KVM bug. Or rather, if it's a KVM "bug", then there's a fundamental
> dependency in memslot management that needs to be rooted out and documented.
Heh, here my surmise is that it cannot be anything but a KVM bug,
because Memslots are not used by anything outside KVM... But maybe I'm
missing something.
> And we're kind of in a catch-22; it'll be extremely difficult to narrow down
> exactly who is breaking what without being able to easily test the optimized
> zapping with other VMMs and/or setups.
I agree with this, and we could have a config symbol that depends on
BROKEN and enables it unconditionally. However a capability is the
wrong tool.
Paolo
next prev parent reply other threads:[~2020-07-09 22:18 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 [this message]
2020-07-10 4:29 ` Sean Christopherson
2020-07-13 18:22 ` Alex Williamson
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=49c7907a-3ab4-b5db-ccb4-190b990c8be3@redhat.com \
--to=pbonzini@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=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).