Received-SPF: pass (google.com: domain of linux-kernel+bounces-101544-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 13 Mar 2024 06:34:03 -0700
In-Reply-To: <72285e50-6ffc-4f24-b97b-8c381b1ddf8e@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>
Message-ID: <ZfGrS4QS_WhBWiDl@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 05:55 schrieb David Stevens:
> > On Thu, Feb 29, 2024 at 10:36=E2=80=AFPM Christoph Hellwig <hch@infrade=
ad.org> wrote:
> > > On Thu, Feb 29, 2024 at 11:57:51AM +0900, David Stevens wrote:
> > > > Our use case is virtio-gpu blob resources [1], which directly map h=
ost
> > > > graphics buffers into the guest as "vram" for the virtio-gpu device=
.
> > > > This feature currently does not work on systems using the amdgpu dr=
iver,
> > > > as that driver allocates non-compound higher order pages via
> > > > ttm_pool_alloc_page().
> > > .. and just as last time around that is still the problem that needs
> > > to be fixed instead of creating a monster like this to map
> > > non-refcounted pages.
> > >=20
> > Patches to amdgpu to have been NAKed [1] with the justification that
> > using non-refcounted pages is working as intended and KVM is in the
> > wrong for wanting to take references to pages mapped with VM_PFNMAP
> > [2].
> >=20
> > The existence of the VM_PFNMAP implies that the existence of
> > non-refcounted pages is working as designed. We can argue about
> > whether or not VM_PFNMAP should exist, but until VM_PFNMAP is removed,
> > KVM should be able to handle it. Also note that this is not adding a
> > new source of non-refcounted pages, so it doesn't make removing
> > non-refcounted pages more difficult, if the kernel does decide to go
> > in that direction.
>=20
> Well, the meaning of VM_PFNMAP is that you should not touch the underlyin=
g
> struct page the PTE is pointing to. As far as I can see this includes
> grabbing a reference count.
>=20
> But that isn't really the problem here. The issue is rather that KVM assu=
mes
> that by grabbing a reference count to the page that the driver won't chan=
ge
> the PTE to point somewhere else.. And that is simply not true.

No, KVM doesn't assume that.

> So what KVM needs to do is to either have an MMU notifier installed so th=
at
> updates to the PTEs on the host side are reflected immediately to the PTE=
s
> on the guest side.

KVM already has an MMU notifier and reacts accordingly.

> Or (even better) you use hardware functionality like nested page tables s=
o
> that we don't actually need to update the guest PTEs when the host PTEs
> change.

That's not how stage-2 page tables work.=20

> 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 when th=
is
> 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 reference,=
 it's
that KVM assumes that any non-reserved pfn that is backed by "struct page" =
is
refcounted.

What Christoph is objecting to is that, in this series, KVM is explicitly a=
dding
support for mapping non-compound (huge)pages into KVM guests.  David is arg=
uing
that Christoph's objection to _KVM_ adding support is unfair, because the r=
eal
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 KVM t=
o follow
and propagate to KVM's stage-2 page tables.