On Thu, 2022-12-22 at 18:15 +0000, Sean Christopherson wrote:

On Wed, Dec 21, 2022, Chao Peng wrote:

quoted

On Tue, Dec 20, 2022 at 08:33:05AM +0000, Huang, Kai wrote:

quoted

On Tue, 2022-12-20 at 15:22 +0800, Chao Peng wrote:

quoted

On Mon, Dec 19, 2022 at 08:48:10AM +0000, Huang, Kai wrote:

quoted

On Mon, 2022-12-19 at 15:53 +0800, Chao Peng wrote:

But for non-restricted-mem case, it is correct for KVM to decrease page's
refcount after setting up mapping in the secondary mmu, otherwise the page will
be pinned by KVM for normal VM (since KVM uses GUP to get the page).

That's true. Actually even true for restrictedmem case, most likely we
will still need the kvm_release_pfn_clean() for KVM generic code. On one
side, other restrictedmem users like pKVM may not require page pinning
at all. On the other side, see below.

quoted

So what we are expecting is: for KVM if the page comes from restricted mem, then
KVM cannot decrease the refcount, otherwise for normal page via GUP KVM should.

No, requiring the user (KVM) to guard against lack of support for page migration
in restricted mem is a terrible API.  It's totally fine for restricted mem to not
support page migration until there's a use case, but punting the problem to KVM
is not acceptable.  Restricted mem itself doesn't yet support page migration,
e.g. explosions would occur even if KVM wanted to allow migration since there is
no notification to invalidate existing mappings.

Yes totally agree (I also replied separately).