[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f49219e-601d-4ddc-a7b7-6ea8968a2f80@linux.intel.com>
Date: Fri, 15 Dec 2023 09:34:16 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Ethan Zhao <haifeng.zhao@...ux.intel.com>, bhelgaas@...gle.com,
dwmw2@...radead.org, will@...nel.org, robin.murphy@....com
Cc: baolu.lu@...ux.intel.com, linux-pci@...r.kernel.org,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
Haorong Ye <yehaorong@...edance.com>
Subject: Re: [PATCH 2/2] iommu/vt-d: don's issue devTLB flush request when
device is disconnected
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
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
Powered by blists - more mailing lists