lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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