On Tue, Sep 13, 2022 at 09:44:27AM +0000, Sean Christopherson wrote:
On Thu, Sep 08, 2022, Kirill A. Shutemov wrote:
On Wed, Aug 31, 2022 at 05:24:39PM +0300, Kirill A . Shutemov wrote:
On Sat, Aug 20, 2022 at 10:15:32PM -0700, Hugh Dickins wrote:
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.)