From: Jason Gunthorpe <jgg@nvidia.com>
To: Steve Sistare <steven.sistare@oracle.com>
Cc: iommu@lists.linux.dev, Kevin Tian <kevin.tian@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
Cornelia Huck <cohuck@redhat.com>
Subject: Re: [RFC V1 0/4] iommufd live update
Date: Mon, 22 Jul 2024 12:55:00 -0300 [thread overview]
Message-ID: <20240722155500.GI3371438@nvidia.com> (raw)
In-Reply-To: <1721501805-86928-1-git-send-email-steven.sistare@oracle.com>
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?
Jason
next prev parent reply other threads:[~2024-07-22 15:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-20 18:56 [RFC V1 0/4] iommufd live update Steve Sistare
2024-07-20 18:56 ` [RFC V1 1/4] iommufd: Export do_update_pinned Steve Sistare
2024-07-20 18:56 ` [RFC V1] iommufd debug print Steve Sistare
2024-07-20 19:01 ` Steven Sistare
2024-07-20 18:56 ` [RFC V1 2/4] iommufd: Lock all objects Steve Sistare
2024-07-22 15:37 ` Jason Gunthorpe
2024-08-05 19:01 ` Steven Sistare
2024-09-26 14:00 ` Steven Sistare
2024-07-20 18:56 ` [RFC V1 3/4] iommufd: Add IOMMU_IOAS_CHANGE_PROCESS Steve Sistare
2024-07-20 18:56 ` [RFC V1 4/4] iommufd: update VA Steve Sistare
2024-07-22 15:51 ` Jason Gunthorpe
2024-08-05 19:02 ` Steven Sistare
2024-08-06 12:54 ` Jason Gunthorpe
2024-07-20 19:21 ` [RFC V1 0/4] iommufd live update Steven Sistare
2024-07-22 15:55 ` Jason Gunthorpe [this message]
2024-08-05 19:03 ` Steven Sistare
2024-08-06 12:56 ` Jason Gunthorpe
2024-08-08 19:15 ` Steven Sistare
2024-08-08 19:52 ` Jason Gunthorpe
2024-08-12 17:41 ` Steven Sistare
2024-08-19 14:59 ` Jason Gunthorpe
2024-08-21 17:54 ` Steven Sistare
2024-08-21 18:04 ` Jason Gunthorpe
2024-08-22 21:05 ` Steven Sistare
2024-08-22 21:10 ` Jason Gunthorpe
2024-07-23 12:48 ` Jason Gunthorpe
2024-08-05 19:02 ` Steven Sistare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240722155500.GI3371438@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=steven.sistare@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.