Re: [RFC PATCH 05/15] iommu: Introduce API to preserve iommu domain

[Samiullah Khawaja]

On Mon, Sep 29, 2025 at 8:54 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
>
> On Sun, Sep 28, 2025 at 07:06:13PM +0000, Samiullah Khawaja wrote:
> > Add an API that can be called by the iommu users to preserve iommu
> > domain. Currently it only marks the iommu_domain as preserved.
>
> Merge it with the previous path
>
> > +#ifdef CONFIG_LIVEUPDATE
> > +     atomic_set(&domain->preserved, 0);
> > +#endif
>
> The memory is kzallocated, I don't think this is needed
>
> > +int iommu_domain_preserve(struct iommu_domain *domain)
> > +{
>
> I expect this to accept some kind of luo pointer to signal what stream
> the domain is part of.
>
> Domains are linked to iommufd's which are linked to luo sessions. This
> all needs to be carefully conveyed down to all the lower levels.
>

Agreed. Currently this is based on LUOv3 and once I rebase on top of
LUOv4 I will rework all this.
> I also expect preserve to return some kind of handle that the caller
> can hide away to deserialize.
>
> > +     lockdep_assert_held(&liveupdate_state_rwsem);
> > +     if (!domain->ops->preserve)
> > +             return -EOPNOTSUPP;
> > +
> > +     ret = domain->ops->preserve(domain);
> > +     if (!ret)
> > +             atomic_set(&domain->preserved, 1);
>
> And if we have a caller handle then there is probably no reason to
> have this state tracking atomic.

Yes, all the domain states can be serialized and backed by the caller
handle. But we will still need to mark the backing iommus for
preservation, because the state of preserved iommus will be needed for
restoration during iommu init during boot. That is why I have a LUO
subsystem registered for IOMMU.
>
> Jason