Re: [RFC PATCH 0/5] iommu/arm-smmu-v3: Implement Runtime/System Sleep ops

[Pranjal Shrivastava <praan@google.com>]

On Wed, Mar 19, 2025 at 04:46:09PM -0300, Jason Gunthorpe wrote:
> On Wed, Mar 19, 2025 at 06:22:30PM +0000, Robin Murphy wrote:
> > I don't see SVA and VFIO needing any special considerations, so it might
> > just be the new vIOMMU stuff which may need to hold PM enabled for the
> > lifetime of things exposed to userspace.
> 
> Are you expecting that the VFIO driver, and whatever driver is
> managing the SVA will keep the power turned on as necessary then?
> 
> VFIO is not going to work if the SMMU power goes off unexpectedly
> while the VFIO FD is open.
> 

In that case, why not hold a ref till the FD is closed? When all the
refs are dropped, we can safely power it down?

> I suppose VFIO also can power off on-demand via userspace asking
> it. In that case the VM would be co-operating.
> 

I'm wondering if user-space / VMM would be willing to control runtime
power at this point? Maybe we could have n VMMs vote when they need
power and drop the votes later and we can simply rpm_get if votes > 0

> vcmdq probably needs some suspend resume logic like the normal
> commandq.
> 

Ack.

> viommu I think will only uses STE fields so it should be OK?
> 

What about IOMMUFD stuff like the Get HW info IOCTL?

> SVA.. Is similar to VFIO, if the power goes off while the SVA is
> working that is bad. The SVA requesting driver would have to manage
> this. HW with userspace command submission probably can't allow the
> power to go off while command submission is possible.
> 

Hmm.. maybe then rpm_get() 

> Jason
Thanks,
Praan