On Tue, Sep 13, 2022 at 09:44:27AM +0000, Sean Christopherson wrote:

On Thu, Sep 08, 2022, Kirill A. Shutemov wrote:

quoted

On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:

quoted

On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:

quoted

quoted

I will try next week to rework it as shim to top of shmem. Does it work
for you?

Yes, please do, thanks.  It's a compromise between us: the initial TDX
case has no justification to use shmem at all, but doing it that way
will help you with some of the infrastructure, and will probably be
easiest for KVM to extend to other more relaxed fd cases later.

Okay, below is my take on the shim approach.

I don't hate how it turned out. It is easier to understand without
callback exchange thing.

The only caveat is I had to introduce external lock to protect against
race between lookup and truncate.

As before, I think this lock is unnecessary.  Or at least it's unnessary to hold
the lock across get/put.  The ->invalidate() call will ensure that the pfn is
never actually used if get() races with truncation.

The updated version you replying to does not use the lock to protect
against truncation anymore. The lock protect notifier list.

Switching topics, what actually prevents mmapp() on the shim?  I tried to follow,
but I don't know these areas well enough.

It has no f_op->mmap, so mmap() will fail with -ENODEV. See do_mmap().
(I did not read the switch statement correctly at first. Note there are
two 'fallthrough' there.)

-- 
  Kiryl Shutsemau / Kirill A. Shutemov