Received-SPF: pass (google.com: domain of linux-kernel+bounces-185696-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 21 May 2024 19:31:31 -0700
In-Reply-To: <Zk1KZDStu/+CR0i4@yzhao56-desk.sh.intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <b89385e5c7f4c3e5bc97045ec909455c33652fb1.camel@intel.com>
 <ZkUIMKxhhYbrvS8I@google.com> <1257b7b43472fad6287b648ec96fc27a89766eb9.camel@intel.com>
 <ZkUVcjYhgVpVcGAV@google.com> <ac5cab4a25d3a1e022a6a1892e59e670e5fff560.camel@intel.com>
 <ZkU7dl3BDXpwYwza@google.com> <175989e7-2275-4775-9ad8-65c4134184dd@intel.com>
 <ZkVDIkgj3lWKymfR@google.com> <7df9032d-83e4-46a1-ab29-6c7973a2ab0b@redhat.com>
 <Zk1KZDStu/+CR0i4@yzhao56-desk.sh.intel.com>
Message-ID: <Zk1ZA-u9yYq0i15-@google.com>
Subject: Re: [PATCH 02/16] KVM: x86/mmu: Introduce a slot flag to zap only
 slot leafs on slot deletion
From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Kai Huang <kai.huang@intel.com>, 
	Rick P Edgecombe <rick.p.edgecombe@intel.com>, "dmatlack@google.com" <dmatlack@google.com>, 
	"sagis@google.com" <sagis@google.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Erdem Aktas <erdemaktas@google.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 22, 2024, Yan Zhao wrote:
> On Fri, May 17, 2024 at 05:30:50PM +0200, Paolo Bonzini wrote:
> > On 5/16/24 01:20, Sean Christopherson wrote:
> > > Hmm, a quirk isn't a bad idea.  It suffers the same problems as a mem=
slot flag,
> > > i.e. who knows when it's safe to disable the quirk, but I would hope =
userspace
> > > would be much, much cautious about disabling a quirk that comes with =
a massive
> > > disclaimer.
> > >=20
> > > Though I suspect Paolo will shoot this down too =F0=9F=98=89
> >=20
> > Not really, it's probably the least bad option.  Not as safe as keying =
it
> > off the new machine types, but less ugly.
> A concern about the quirk is that before identifying the root cause of th=
e
> issue, we don't know which one is a quirk, fast zapping all TDPs or slow =
zapping
> within memslot range.

The quirk is specifically that KVM zaps SPTEs that aren't related to the me=
mslot
being deleted/moved.  E.g. the issue went away if KVM zapped a rather arbit=
rary
set of SPTEs.  IIRC, there was a specific gfn range that was "problematic",=
 but
we never figured out the correlation between the problematic range and the =
memslot
being deleted.

Disabling the quirk would allow KVM to choose between a slow/precise/partia=
l zap,
and full/fast zap.