On 12/15/2023 9:34 AM, Baolu Lu wrote:
On 2023/12/15 9:03, Ethan Zhao wrote:
2. supprise_removal
Users remove the devece directly or bring the device link down/turn
off
device power first by setting pci config space, link-down/not-present/
power-off are all handled by pciehp the same way
"supprise_removal", in
such case, pciehp_ist() will flag the device as "disconnected"
first, then
unconfig the devcie, unload driver, iommu release device(issing
devTLB flush)
delete device. so we checking the device state could work such cases.
If so, then it is fine for the iommu driver. As Robin said, if the
device needs more cleanup, the iommu core should register a right
callback to the driver core and handle it before the device goes away.
Disabling PCI features seems to be a reasonable device cleanup. This
gives us another reason to move ATS enabling/disabling out from the
For supprise_removal, device was already removed, powered-off, iommu
device-release got notification or cleanup callback is invoked to disable
ATS to not-present device etc ,
I didn't get the meaning to do so, perhaps I misunderstand ?
Thanks,
Ethan
iommu subsystem. Once this is done, the device driver will enable ATS
during its probe and disable it during its release. There will be no
such workaround in the iommu driver anymore.
Best regards,
baolu
