On Mon, Sep 16, 2024 at 01:31:00PM +0200, James Gowans wrote:
> diff --git a/drivers/iommu/iommufd/serialise.c b/drivers/iommu/iommufd/serialise.c
> index 9519969bd201..baac7d6150cb 100644
> --- a/drivers/iommu/iommufd/serialise.c
> +++ b/drivers/iommu/iommufd/serialise.c
> @@ -139,7 +139,14 @@ static int rehydrate_iommufd(char *iommufd_name)
> area->node.last = *iova_start + *iova_len - 1;
> interval_tree_insert(&area->node, &ioas->iopt.area_itree);
> }
> - /* TODO: restore link from ioas to hwpt. */
> + /*
> + * Here we should do something to associate struct iommufd_device with the
> + * ictx, then get the iommu_ops via dev_iommu_ops(), and call the new
> + * .domain_restore callback to get the struct iommu_domain.
> + * Something like:
> + * hwpt->domain = ops->domain_restore(dev, persistent_id);
> + * Hand wavy - the details allude me at the moment...
> + */
> }
The core code should request a iommu_domain handle for the
pre-existing translation very early on, it should not leave the device
in some weird NULL domain state. I have been trying hard to eliminate
that.
The special domain would need to remain attached and some protocol
would be needed to carefully convey that past vfio to iommufd,
including inhibiting attaching a blocked domain in VFIO
startup. Including blocking FLRs from VFIO and rejecting attaches to
other non-VFIO drivers.
This is a twisty complicated path, it needs some solid definition of
what the lifecycle of this special domain is, and some sensible exits
if userspace isn't expecting/co-operating with the hand over, or it
crashes while doing this..
> @@ -576,6 +578,9 @@ struct iommu_ops {
> struct iommu_domain *(*domain_alloc_sva)(struct device *dev,
> struct mm_struct *mm);
>
> + struct iommu_domain *(*domain_restore)(struct device *dev,
> + unsigned long persistent_id);
> +
Why do we need an ID? There is only one persistent domain per device,
right?
This may need PASID, at least Intel requires the hypervisor to handle
PASID domains, and they would need to persist as well.
Jason
