Received-SPF: pass (google.com: domain of linux-kernel+bounces-101638-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 13 Mar 2024 07:48:51 -0700
In-Reply-To: <0b109bc4-ee4c-4f13-996f-b89fbee09c0b@amd.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240229025759.1187910-1-stevensd@google.com> <ZeCIX5Aw5s1L0YEh@infradead.org>
 <CAD=HUj7fT2CVXLfi5mty0rSzpG_jK9fhcKYGQnTf_H8Hg-541Q@mail.gmail.com>
 <72285e50-6ffc-4f24-b97b-8c381b1ddf8e@amd.com> <ZfGrS4QS_WhBWiDl@google.com> <0b109bc4-ee4c-4f13-996f-b89fbee09c0b@amd.com>
Message-ID: <ZfG801lYHRxlhZGT@google.com>
Subject: Re: [PATCH v11 0/8] KVM: allow mapping non-refcounted pages
From: Sean Christopherson <seanjc@google.com>
To: "Christian =?utf-8?B?S8O2bmln?=" <christian.koenig@amd.com>
Cc: David Stevens <stevensd@chromium.org>, Christoph Hellwig <hch@infradead.org>, 
	Paolo Bonzini <pbonzini@redhat.com>, Yu Zhang <yu.c.zhang@linux.intel.com>, 
	Isaku Yamahata <isaku.yamahata@gmail.com>, Zhi Wang <zhi.wang.linux@gmail.com>, 
	Maxim Levitsky <mlevitsk@redhat.com>, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, 
	kvm@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2024, Christian K=C3=B6nig wrote:
> Am 13.03.24 um 14:34 schrieb Sean Christopherson:
> > On Wed, Mar 13, 2024, Christian K=C3=B6nig wrote:
> > > And when you have either of those two functionalities the requirement=
 to add
> > > a long term reference to the struct page goes away completely. So whe=
n this
> > > is done right you don't need to grab a reference in the first place.
> > The KVM issue that this series is solving isn't that KVM grabs a refere=
nce, it's
> > that KVM assumes that any non-reserved pfn that is backed by "struct pa=
ge" is
> > refcounted.
>=20
> Well why does it assumes that? When you have a MMU notifier that seems
> unnecessary.

Indeed, it's legacy code that we're trying to clean up.  It's the bulk of t=
his
series.

> > What Christoph is objecting to is that, in this series, KVM is explicit=
ly adding
> > support for mapping non-compound (huge)pages into KVM guests.  David is=
 arguing
> > that Christoph's objection to _KVM_ adding support is unfair, because t=
he real
> > problem is that the kernel already maps such pages into host userspace.=
  I.e. if
> > the userspace mapping ceases to exist, then there are no mappings for K=
VM to follow
> > and propagate to KVM's stage-2 page tables.
>=20
> And I have to agree with Christoph that this doesn't make much sense. KVM
> should *never* map (huge) pages from VMAs marked with VM_PFNMAP into KVM
> guests in the first place.
>=20
> What it should do instead is to mirror the PFN from the host page tables
> into the guest page tables.

That's exactly what this series does.  Christoph is objecting to KVM playin=
g nice
with non-compound hugepages, as he feels that such mappings should not exis=
t
*anywhere*.

I.e. Christoph is (implicitly) saying that instead of modifying KVM to play=
 nice,
we should instead fix the TTM allocations.  And David pointed out that that=
 was
tried and got NAK'd.