On Tue, Sep 13, 2022, Kirill A. Shutemov wrote: > 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. Gah, grabbed the patch when applying. > > 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.) Ah, validate_mmap_request(). Thought not implementing ->mmap() was the key, but couldn't find the actual check. Thanks much!
