From: Baolu Lu <baolu.lu@linux.intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Xiongfeng Wang <wangxiongfeng2@huawei.com>,
Yang Yingliang <yangyingliang@huawei.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] iommu/vt-d: Add a fix for devices need extra dtlb flush
Date: Thu, 1 Dec 2022 16:36:26 +0800 [thread overview]
Message-ID: <edbcfb02-0c20-5444-b2fa-34189faa923d@linux.intel.com> (raw)
In-Reply-To: <20221201040127.1962750-2-baolu.lu@linux.intel.com>
On 2022/12/1 12:01, Lu Baolu wrote:
> From: Jacob Pan<jacob.jun.pan@linux.intel.com>
>
> QAT devices on Intel Sapphire Rapids and Emerald Rapids have a defect in
> address translation service (ATS). These devices may inadvertently issue
> ATS invalidation completion before posted writes initiated with
> translated address that utilized translations matching the invalidation
> address range, violating the invalidation completion ordering.
>
> This patch adds an extra device TLB invalidation for the affected devices,
> it is needed to ensure no more posted writes with translated address
> following the invalidation completion. Therefore, the ordering is
> preserved and data-corruption is prevented.
>
> Device TLBs are invalidated under the following six conditions:
> 1. Device driver does DMA API unmap IOVA
> 2. Device driver unbind a PASID from a process, sva_unbind_device()
> 3. PASID is torn down, after PASID cache is flushed. e.g. process
> exit_mmap() due to crash
> 4. Under SVA usage, called by mmu_notifier.invalidate_range() where
> VM has to free pages that were unmapped
> 5. userspace driver unmaps a DMA buffer
> 6. Cache invalidation in vSVA usage (upcoming)
>
> For #1 and #2, device drivers are responsible for stopping DMA traffic
> before unmap/unbind. For #3, iommu driver gets mmu_notifier to
> invalidate TLB the same way as normal user unmap which will do an extra
> invalidation. The dTLB invalidation after PASID cache flush does not
> need an extra invalidation.
>
> Therefore, we only need to deal with #4 and #5 in this patch. #1 is also
> covered by this patch due to common code path with #5.
>
> Tested-by: Yuzhang Luo<yuzhang.luo@intel.com>
> Reviewed-by: Ashok Raj<ashok.raj@intel.com>
> Reviewed-by: Kevin Tian<kevin.tian@intel.com>
This missed cc stable tag.
Cc: stable@vger.kernel.org # v5.15+
Sorry for the inconvenience.
> Signed-off-by: Jacob Pan<jacob.jun.pan@linux.intel.com>
> Link:https://lore.kernel.org/r/20221130062449.1360063-1-jacob.jun.pan@linux.intel.com
> Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com>
> ---
> drivers/iommu/intel/iommu.h | 4 +++
> drivers/iommu/intel/iommu.c | 69 +++++++++++++++++++++++++++++++++++--
> drivers/iommu/intel/svm.c | 5 ++-
> 3 files changed, 75 insertions(+), 3 deletions(-)
Best regards,
baolu
next prev parent reply other threads:[~2022-12-01 8:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 4:01 [PATCH 0/4] [PULL REQUEST] iommu/vt-d: Fixes for v6.1-rc8 Lu Baolu
2022-12-01 4:01 ` [PATCH 1/4] iommu/vt-d: Add a fix for devices need extra dtlb flush Lu Baolu
2022-12-01 8:36 ` Baolu Lu [this message]
2022-12-01 4:01 ` [PATCH 2/4] iommu/vt-d: Fix PCI device refcount leak in prq_event_thread() Lu Baolu
2022-12-01 4:01 ` [PATCH 3/4] iommu/vt-d: Fix PCI device refcount leak in has_external_pci() Lu Baolu
2022-12-01 4:01 ` [PATCH 4/4] iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() Lu Baolu
2022-12-02 10:47 ` [PATCH 0/4] [PULL REQUEST] iommu/vt-d: Fixes for v6.1-rc8 Joerg Roedel
2022-12-03 0:54 ` Jacob Pan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edbcfb02-0c20-5444-b2fa-34189faa923d@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wangxiongfeng2@huawei.com \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.