From: Jason Gunthorpe <jgg@ziepe.ca>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
David Woodhouse <dwmw2@infradead.org>,
Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
iommu@lists.linux.dev, YiFei Zhu <zhuyifei@google.com>,
Robin Murphy <robin.murphy@arm.com>,
Pratyush Yadav <pratyush@kernel.org>,
Kevin Tian <kevin.tian@intel.com>,
linux-kernel@vger.kernel.org, Saeed Mahameed <saeedm@nvidia.com>,
Adithya Jayachandran <ajayachandra@nvidia.com>,
Parav Pandit <parav@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>, William Tu <witu@nvidia.com>,
Vipin Sharma <vipinsh@google.com>,
dmatlack@google.com, Chris Li <chrisl@kernel.org>,
praan@google.com
Subject: Re: [RFC PATCH 13/15] iommufd: Persist iommu domains for live update
Date: Thu, 2 Oct 2025 18:12:17 -0300 [thread overview]
Message-ID: <20251002211217.GI3195829@ziepe.ca> (raw)
In-Reply-To: <CAAywjhQGQx2_2X8r0rf3AgMDbJj-9C=9_1a3xgiLwuzKLAvXCQ@mail.gmail.com>
On Thu, Oct 02, 2025 at 12:29:25PM -0700, Samiullah Khawaja wrote:
> I had a quick discussion with Pasha to see how LUO can help with FD
> dependencies and FINISH order. Perhaps we need a new LUO API that
> iommufd can call before live update, explicitly telling LUO that it
> depends on an FD that is going to be preserved.
Keeping track of a dependency graph is possible.
But I wonder if it is really needed to be fine grained.
If a memfd remains frozen until finish, and finish can't happen until
all luo objects that are internally refering to outside memory
indicate they are done, don't we get the same outcome?
Is there a reason a specific memfd should be unfrozen before finish?
Maybe finish is too broad grained? What if each session had a finish?
All the objects in the session are cleaned up, invoke the session
finish and the memfd's in the session unfreeze?
Otherwise to build a dependency graph we'd need things like
iommu_domain to record all the memfds/etc stored within it and
preserve that and so on. This information has to come from the IOAS in
iommfd so it is quite a bit more weirdness to inject.
Whereas if we have the preserving iommufd do a sequence where it
pushes all the ioas pages (memfd/etc) to luo, and only then permits
the hwpt to be preserved to the same session, we get the same basic
tracking without needing to store a graph.
Donno...
Jason
next prev parent reply other threads:[~2025-10-02 21:12 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 19:06 [RFC PATCH 00/15] iommu: Add live update state preservation Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 01/15] iommu/vt-d: Register with Live Update Orchestrator Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 02/15] iommu: Add rw_semaphore to serialize live update state Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 03/15] iommu/vt-d: Prevent hotplugs when live update state is not normal Samiullah Khawaja
2025-09-29 15:51 ` Jason Gunthorpe
2025-09-29 16:50 ` Pasha Tatashin
2025-09-29 17:21 ` Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 04/15] iommu: Add preserve iommu_domain op Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 05/15] iommu: Introduce API to preserve iommu domain Samiullah Khawaja
2025-09-29 15:54 ` Jason Gunthorpe
2025-09-29 18:11 ` Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 06/15] iommu/vt-d: Add stub intel iommu domain preserve op Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 07/15] iommu/vt-d: Add implementation of live update prepare callback Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 08/15] iommu/vt-d: Implement live update preserve_iommu_context Samiullah Khawaja
2025-09-29 15:57 ` Jason Gunthorpe
2025-09-28 19:06 ` [RFC PATCH 09/15] iommu/vt-d: Add live update freeze callback Samiullah Khawaja
2025-09-29 15:58 ` Jason Gunthorpe
2025-09-28 19:06 ` [RFC PATCH 10/15] iommu/vt-d: Restore iommu root_table and context on live update Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 11/15] iommufd: Add basic skeleton based on liveupdate_file_handle Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 12/15] iommufd-luo: Implement basic prepare/cancel/finish/retrieve using folios Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 13/15] iommufd: Persist iommu domains for live update Samiullah Khawaja
2025-09-29 16:00 ` Jason Gunthorpe
2025-09-29 17:32 ` Samiullah Khawaja
2025-09-29 17:43 ` Jason Gunthorpe
2025-09-29 17:45 ` Pasha Tatashin
2025-09-30 13:07 ` Pasha Tatashin
2025-09-30 13:59 ` Jason Gunthorpe
2025-09-30 15:09 ` Pasha Tatashin
2025-09-30 16:31 ` Jason Gunthorpe
2025-09-30 20:02 ` Samiullah Khawaja
2025-09-30 21:05 ` Jason Gunthorpe
2025-09-30 23:15 ` Samiullah Khawaja
2025-10-01 11:47 ` Jason Gunthorpe
2025-10-01 19:28 ` Pasha Tatashin
2025-10-02 11:57 ` Jason Gunthorpe
2025-10-02 14:43 ` Pasha Tatashin
2025-10-02 15:10 ` Jason Gunthorpe
2025-10-02 19:29 ` Samiullah Khawaja
2025-10-02 21:12 ` Jason Gunthorpe [this message]
2025-10-02 21:30 ` Pasha Tatashin
2025-10-02 22:58 ` Jason Gunthorpe
2025-10-02 23:56 ` Samiullah Khawaja
2025-10-03 12:09 ` Jason Gunthorpe
2025-10-02 1:00 ` Samiullah Khawaja
2025-10-02 13:41 ` Jason Gunthorpe
2025-10-02 14:59 ` Pasha Tatashin
2025-10-02 17:03 ` Samiullah Khawaja
2025-10-02 17:37 ` Jason Gunthorpe
2025-10-02 18:08 ` Samiullah Khawaja
2025-10-10 1:28 ` Pasha Tatashin
2025-10-10 14:24 ` Jason Gunthorpe
2025-09-28 19:06 ` [RFC PATCH 14/15] iommu/vt-d: sanitize restored root table and iommu contexts Samiullah Khawaja
2025-09-28 19:06 ` [RFC PATCH 15/15] iommufd/selftest: Add test to verify iommufd preservation Samiullah Khawaja
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=20251002211217.GI3195829@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=ajayachandra@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=chrisl@kernel.org \
--cc=dmatlack@google.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=parav@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=praan@google.com \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saeedm@nvidia.com \
--cc=skhawaja@google.com \
--cc=vipinsh@google.com \
--cc=will@kernel.org \
--cc=witu@nvidia.com \
--cc=zhuyifei@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox