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

[Pranjal Shrivastava <praan@google.com>]

On Thu, Mar 20, 2025 at 08:08:13PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 20, 2025 at 09:00:57PM +0000, Pranjal Shrivastava wrote:
> > 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 assume VFIO is already doing that?? It must be keeping the PCI
> device powered up, doesn't that automatically keep the SMMU powered
> too?
> 

Yes it should if the devlinks are setup correctly.

> 
> > > 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
> 
> Yeah, I imagine that is how it would have to work. 
> 
> > > viommu I think will only uses STE fields so it should be OK?
> > > 
> > 
> > What about IOMMUFD stuff like the Get HW info IOCTL?
> 
> Isn't that all from SW caches?
>  

Not really? I see arm_smmu_hw_info reads all the IDR registers..
The call flow I could trace is like:

iommufd_get_hw_info()
 -> iommu_ops->hw_info()
   -> arm_smmu_hw_info()

Am I missing something here?

> > > 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() 
> 
> Again mostly assuming the SVA using driver is already doing this
> somehow?
> 

Hmm.. yea it should happen through devlinks too.. Let me re-check if
there's a surprise somewhere.

> Jason

Thanks
Praan