Linux IOMMU Development
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Mostafa Saleh <smostafa@google.com>,
	Daniel Mentz <danielmentz@google.com>,
	iommu@lists.linux.dev
Subject: Re: [RFC PATCH 3/5] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
Date: Wed, 16 Apr 2025 12:52:28 +0000	[thread overview]
Message-ID: <Z_-oDPaAgLaXcrfC@google.com> (raw)
In-Reply-To: <20250416124252.GD493866@ziepe.ca>

On Wed, Apr 16, 2025 at 09:42:52AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 16, 2025 at 12:29:05PM +0000, Pranjal Shrivastava wrote:
> > On Wed, Apr 16, 2025 at 09:02:51AM -0300, Jason Gunthorpe wrote:
> > > On Wed, Apr 16, 2025 at 10:24:52AM +0000, Pranjal Shrivastava wrote:
> > > 
> > > > Also, this would mean that we'll have to take care if the Guest Kernel
> > > > ends up touching the mmio region while the SMMU is suspended?
> > > 
> > > I think this is approaching it backwards.
> > > 
> > > If power management is supported then the power should be on unless
> > > the VM has activated its own virtual power management. VM virtual
> > > power mangement would flush the cmdq from the VM side then signal the
> > > host that it is OK to power down the SMMU, which the host may or may
> > > not do
> > > 
> > > It doesn't make alot of sense to power down the SMMU while a VM is
> > > running...
> > > 
> > 
> > Exactly, that's what I meant to convey..
> > So.. can't we simply take a ref as soon as a VM is created (IOMMU is
> > assigned to it), maybe from somewhere like vfio_change_dma_owner and
> > keep things powered on? That way we keep the IOMMU powered ON if it's
> > controlled by the userspace.
> > 
> > This would also allow us to only care about the host-managed queues
> > while suspening because we'll be sure that if we are suspending the
> > IOMMU, no VM is active.
> 
> I thought we agreed VFIO already would need to do something to keep
> the power on as it can do DMA at any time?
> 

Yes.. but if that's the case why are the Guest-assigned vCMDQs coming
into the picture? 

I assumed that there's a situation where the VMM doesn't use
VFIO and only uses iommufd to assign/configure the IOMMU, maybe we'd
need to get a pm ref there as well? Is that the case?

Otherwise, if we have any user-space entity controlling a device behind
the IOMMU, we'd grab a pm ref and not power down. And hence, we won't
need any special handling for Guest-assigned vCMDQs because the IOMMU is
powered on.

Please tell me if I'm missing something? 

> Jason

Thanks
Praan

  reply	other threads:[~2025-04-16 12:52 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19  0:42 [RFC PATCH 0/5] iommu/arm-smmu-v3: Implement Runtime/System Sleep ops Pranjal Shrivastava
2025-03-19  0:42 ` [RFC PATCH 1/5] iommu/arm-smmu-v3: Refactor arm_smmu_setup_irqs Pranjal Shrivastava
2025-03-19  4:50   ` Nicolin Chen
2025-03-19  7:43     ` Pranjal Shrivastava
2025-03-20 22:29   ` Mostafa Saleh
2025-03-21  7:26     ` Pranjal Shrivastava
2025-03-25 16:19   ` Daniel Mentz
2025-03-26 19:35     ` Pranjal Shrivastava
2025-03-19  0:42 ` [RFC PATCH 2/5] iommu/arm-smmu-v3: Add a helper to wait till cmdq drains Pranjal Shrivastava
2025-03-20 22:30   ` Mostafa Saleh
2025-03-21  8:09     ` Pranjal Shrivastava
2025-03-25 17:50   ` Daniel Mentz
2025-03-26 19:36     ` Pranjal Shrivastava
2025-03-26  4:51   ` Daniel Mentz
2025-03-26 20:10     ` Pranjal Shrivastava
2025-03-19  0:42 ` [RFC PATCH 3/5] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops Pranjal Shrivastava
2025-03-20 22:33   ` Mostafa Saleh
2025-03-21  8:13     ` Pranjal Shrivastava
2025-03-26  4:52   ` Daniel Mentz
2025-03-28  7:47     ` Pranjal Shrivastava
2025-04-14 17:57   ` Nicolin Chen
2025-04-14 21:26     ` Nicolin Chen
2025-04-15 20:47       ` Pranjal Shrivastava
2025-04-15 22:28         ` Nicolin Chen
2025-04-16 10:24           ` Pranjal Shrivastava
2025-04-16 12:02             ` Jason Gunthorpe
2025-04-16 12:29               ` Pranjal Shrivastava
2025-04-16 12:42                 ` Jason Gunthorpe
2025-04-16 12:52                   ` Pranjal Shrivastava [this message]
2025-04-16 13:07                     ` Jason Gunthorpe
2025-04-16 14:32                       ` Pranjal Shrivastava
2025-04-15 20:37     ` Pranjal Shrivastava
2025-04-15 22:13       ` Nicolin Chen
2025-04-16  8:29         ` Pranjal Shrivastava
2025-03-19  0:42 ` [RFC PATCH 4/5] iommu/arm-smmu-v3: Enable pm_runtime and setup devlinks Pranjal Shrivastava
2025-03-20 22:34   ` Mostafa Saleh
2025-03-19  0:42 ` [RFC PATCH 5/5] iommu/arm-smmu-v3: Invoke pm_runtime before hw access Pranjal Shrivastava
2025-03-19 12:04   ` Jason Gunthorpe
2025-03-20  7:25     ` Pranjal Shrivastava
2025-03-20 12:54       ` Jason Gunthorpe
2025-03-20 13:22         ` Robin Murphy
2025-03-20 14:21           ` Pranjal Shrivastava
2025-03-20 22:36   ` Mostafa Saleh
2025-03-19 11:57 ` [RFC PATCH 0/5] iommu/arm-smmu-v3: Implement Runtime/System Sleep ops Jason Gunthorpe
2025-03-19 16:07   ` Robin Murphy
2025-03-20 22:25     ` Mostafa Saleh
2025-03-21 14:18       ` Pranjal Shrivastava
2025-03-21 17:35         ` Robin Murphy
2025-03-24 17:36           ` Pranjal Shrivastava
2025-03-27 17:27             ` Mostafa Saleh
2025-03-28  9:13               ` Pranjal Shrivastava
2025-03-28  9:19                 ` Pranjal Shrivastava
2025-03-28 13:18                 ` Jason Gunthorpe
2025-03-28 15:08                   ` Pranjal Shrivastava
2025-03-28 18:21                     ` Jason Gunthorpe
2025-03-19 18:22 ` Robin Murphy
2025-03-19 19:46   ` Jason Gunthorpe
2025-03-20 21:00     ` Pranjal Shrivastava
2025-03-20 23:08       ` Jason Gunthorpe
2025-03-21 14:36         ` Pranjal Shrivastava
2025-03-22  0:00           ` Jason Gunthorpe
2025-03-20 22:28     ` Mostafa Saleh
2025-03-20 23:05       ` Jason Gunthorpe
2025-03-21 14:44         ` Pranjal Shrivastava
2025-03-21 15:30           ` Jason Gunthorpe
2025-03-24 17:53             ` Pranjal Shrivastava
2025-03-25 13:55               ` Jason Gunthorpe
2025-03-27 17:39                 ` Mostafa Saleh
2025-03-28 13:21                   ` Jason Gunthorpe
2025-03-20 14:13   ` Pranjal Shrivastava
2025-03-20 14:54     ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_-oDPaAgLaXcrfC@google.com \
    --to=praan@google.com \
    --cc=danielmentz@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=nicolinc@nvidia.com \
    --cc=robin.murphy@arm.com \
    --cc=smostafa@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox