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.) -- Kiryl Shutsemau / Kirill A. Shutemov
