Re: [RFC V1 0/4] iommufd live update

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Aug 05, 2024 at 03:03:30PM -0400, Steven Sistare wrote:
> On 7/22/2024 11:55 AM, Jason Gunthorpe wrote:
> > On Sat, Jul 20, 2024 at 11:56:40AM -0700, Steve Sistare wrote:
> > > Live update is a technique wherein an application saves its state, launches
> > > an updated version of itself, and restores its state.  Clients of the
> > > application experience a brief suspension of service, on the order of
> > > 100's of milliseconds, but are otherwise unaffected.
> > > 
> > > Define the IOMMU_IOAS_CHANGE_PROCESS ioctl to allow management and use
> > > of an iommufd device to be transferred from one process to another.  The
> > > application is responsible for transferring the device descriptor to the new
> > > process, eg either by preservation across fork and exec or via SCM_RIGHTS.
> > 
> > It seems Ok to me, I'm glad it worked out for you
> > 
> > But have you considered using something like the new
> > memfd_pin_folios() system so that iommufd is bound to the FDs backing
> > the memory instead of VMAs?
> > 
> > https://lore.kernel.org/all/20240624063952.1572359-1-vivek.kasireddy@intel.com/
> > 
> > I've been expecting to add support for that, but does it help this scenario?
> 
> Thanks for the pointer, I had not seen it.
> AFAICT it does not affect live update.  The memfd is passed to new qemu, and
> the manner in which its pages were pinned does not matter, as long as the effect
> on the mm fields that we manipulate is the same.

I mean instead of using mmap's() and telling iommfd to take the pages
from a VMA you'd use a memfd and tell iommufd to take the pages from
the memfd directly.

Since the memfd is not part of a process or mm_struct it is not
effected by live update's exec() and none of these gyrations are
necessary.

Jason