[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEiTSgK/PLVJ1XEz@nvidia.com>
Date: Tue, 10 Jun 2025 13:19:22 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Robin Murphy <robin.murphy@....com>, Baolu Lu <baolu.lu@...ux.intel.com>,
<joro@...tes.org>, <will@...nel.org>, <bhelgaas@...gle.com>,
<iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
<linux-pci@...r.kernel.org>, <patches@...ts.linux.dev>,
<pjaroszynski@...dia.com>, <vsethi@...dia.com>
Subject: Re: [PATCH RFC v1 1/2] iommu: Introduce iommu_dev_reset_prepare()
and iommu_dev_reset_done()
On Tue, Jun 10, 2025 at 01:43:06PM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 10, 2025 at 05:31:09PM +0100, Robin Murphy wrote:
> > From a quick skim I suspect it's probably OK - at least device_del() gets to
> > bus_remove_device()->device_remove_groups() well enough before the
> > BUS_NOTIFY_REMOVED_DEVICE call that triggers iommu_release_device().
>
> Make sense, Nicolin, a well placed comment explaining this would be
> good
Ack.
> > And on an unrelated thought that's just come to mind, if we ever did FLR
> > with PASIDs enabled, presumably that's going to wipe out the PASID
> > configuration,
>
> I've always been expecting the PCI FLR code to preserve the config
> space that belongs the iommu subsystem. PASID, ATS, PRI, etc. Never
> looked into it... Nicolin??
Those are the flags in struct pci_dev right?
unsigned int ats_enabled:1; /* Address Translation Svc */
unsigned int pasid_enabled:1; /* Process Address Space ID */
unsigned int pri_enabled:1; /* Page Request Interface */
And pci_restore_state() does the recovery of these bits.
Thanks
Nicolin
Powered by blists - more mailing lists