On Wed, Jun 19, 2024 at 01:01:14PM +0100, Fuad Tabba wrote: > Hi Jason, > > On Wed, Jun 19, 2024 at 12:51 PM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > > On Wed, Jun 19, 2024 at 10:11:35AM +0100, Fuad Tabba wrote: > > > > > To be honest, personally (speaking only for myself, not necessarily > > > for Elliot and not for anyone else in the pKVM team), I still would > > > prefer to use guest_memfd(). I think that having one solution for > > > confidential computing that rules them all would be best. But we do > > > need to be able to share memory in place, have a plan for supporting > > > huge pages in the near future, and migration in the not-too-distant > > > future. > > > > I think using a FD to control this special lifetime stuff is > > dramatically better than trying to force the MM to do it with struct > > page hacks. > > > > If you can't agree with the guest_memfd people on how to get there > > then maybe you need a guest_memfd2 for this slightly different special > > stuff instead of intruding on the core mm so much. (though that would > > be sad) > > > > We really need to be thinking more about containing these special > > things and not just sprinkling them everywhere. > > I agree that we need to agree :) This discussion has been going on > since before LPC last year, and the consensus from the guest_memfd() > folks (if I understood it correctly) is that guest_memfd() is what it > is: designed for a specific type of confidential computing, in the > style of TDX and CCA perhaps, and that it cannot (or will not) perform > the role of being a general solution for all confidential computing. If you can't agree with guest_memfd, that just says you need Yet Another FD, not mm hacks. IMHO there is nothing intrinsically wrong with having the various FD types being narrowly tailored to their use case. Not to say sharing wouldn't be nice too. Jason
