[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250930163111.GO2695987@ziepe.ca>
Date: Tue, 30 Sep 2025 13:31:11 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Samiullah Khawaja <skhawaja@...gle.com>,
David Woodhouse <dwmw2@...radead.org>,
Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>,
Will Deacon <will@...nel.org>, iommu@...ts.linux.dev,
YiFei Zhu <zhuyifei@...gle.com>,
Robin Murphy <robin.murphy@....com>,
Pratyush Yadav <pratyush@...nel.org>,
Kevin Tian <kevin.tian@...el.com>, linux-kernel@...r.kernel.org,
Saeed Mahameed <saeedm@...dia.com>,
Adithya Jayachandran <ajayachandra@...dia.com>,
Parav Pandit <parav@...dia.com>,
Leon Romanovsky <leonro@...dia.com>, William Tu <witu@...dia.com>,
Vipin Sharma <vipinsh@...gle.com>, dmatlack@...gle.com,
Chris Li <chrisl@...nel.org>, praan@...gle.com
Subject: Re: [RFC PATCH 13/15] iommufd: Persist iommu domains for live update
On Tue, Sep 30, 2025 at 11:09:59AM -0400, Pasha Tatashin wrote:
>
> The way LUOv4 is implemented, "LUO sessions" are always participating
> LU. Once a user adds file descriptors to a session, that session and
> its contents are automatically carried across multiple consecutive
> live updates. The user only needs to act if they explicitly want to
> remove an FD and opt-out of preservation, or close session. This is
> consistent and convenient for long-running VM that should survive by
> default.
I don't think this is a good idea. Each kernel should decide on its
own what and how things get included and manage the labels, from
scratch.
If you do this then alot more stuff becomes ABI and I think it will
turn into a huge PITA.
The userspace already has to have the code to setup the luo if it is
on a clean reboot - what is the point of not running that every time?
Jason
Powered by blists - more mailing lists