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. Switching topics, what actually prevents mmapp() on the shim? I tried to follow, but I don't know these areas well enough.
