On Sat, 20 Aug 2022, Kirill A. Shutemov wrote: > > Yes, INACCESSIBLE is increase of complexity which you do not want to deal > with in shmem.c. It get it. It's not so much that INACCESSIBLE increases the complexity of memfd/shmem/tmpfs, as that it is completely foreign to it. And by handling all those foreign needs at the KVM end (where you can be sure that the mem attached to the fd is INACCESSIBLE because you have given nobody access to it - no handshaking with 3rd party required). > > 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. > > But I think it is wrong to throw it over the fence to KVM folks and say it > is your problem. Core MM has to manage it. We disagree on who is throwing over the fence to whom :) Core MM should manage the core MM parts and KVM should manage the KVM parts. What makes this rather different from most driver usage of MM, is that KVM seems likely to use a great proportion of memory this way. With great memory usage comes great responsibility: I don't think all those flags and seals and notifiers let KVM escape from that. Hugh
