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
