From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: dwmw2@infradead.org, baolu.lu@linux.intel.com, joro@8bytes.org,
zhangfei.gao@linaro.org, wangzhou1@hisilicon.com
Cc: arnd@arndb.de, gregkh@linuxfoundation.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-accelerators@lists.ozlabs.org, kevin.tian@intel.com,
jacob.jun.pan@linux.intel.com, ashok.raj@intel.com,
linux-pci@vger.kernel.org,
Jean-Philippe Brucker <jean-philippe@linaro.org>
Subject: [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes
Date: Thu, 15 Oct 2020 11:00:27 +0200 [thread overview]
Message-ID: <20201015090028.1278108-1-jean-philippe@linaro.org> (raw)
Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver
whether the PRI queue needs flushing. When looking at the PCIe spec
again I noticed that most of the time the SMMUv3 driver doesn't actually
need to flush the PRI queue. Does this make sense for Intel VT-d as well
or did I overlook something?
Before calling iommu_sva_unbind_device(), device drivers must stop the
device from using the PASID. For PCIe devices, that consists of
completing any pending DMA, and completing any pending page request
unless the device uses Stop Markers. So unless the device uses Stop
Markers, we don't need to flush the PRI queue. For SMMUv3, stopping DMA
means completing all stall events, so we never need to flush the event
queue.
First patch adds flags to unbind(), and the second one lets device
drivers tell whether the PRI queue needs to be flushed.
Other remarks:
* The PCIe spec (see quote on patch 2), says that the device signals
whether it has sent a Stop Marker or not during Stop PASID. In reality
it's unlikely that a given device will sometimes use one stop method
and sometimes the other, so it could be a device-wide flag rather than
passing it at each unbind(). I don't want to speculate too much about
future implementation so I prefer having the flag in unbind().
* In patch 1, uacce passes 0 to unbind(). To pass the right flag I'm
thinking that uacce->ops->stop_queue(), which tells the device driver
to stop DMA, should return whether faults are pending. This can be
added later once uacce has an actual PCIe user, but we need to
remember to do it.
Jean-Philippe Brucker (2):
iommu: Add flags to sva_unbind()
iommu: Add IOMMU_UNBIND_FAULT_PENDING flag
include/linux/intel-iommu.h | 2 +-
include/linux/iommu.h | 38 ++++++++++++++++++++++++++++++++++---
drivers/iommu/intel/svm.c | 10 ++++++----
drivers/iommu/iommu.c | 10 +++++++---
drivers/misc/uacce/uacce.c | 4 ++--
5 files changed, 51 insertions(+), 13 deletions(-)
--
2.28.0
next reply other threads:[~2020-10-15 9:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 9:00 Jean-Philippe Brucker [this message]
2020-10-15 9:00 ` [RFC PATCH 1/2] iommu: Add flags to sva_unbind() Jean-Philippe Brucker
2020-10-15 9:00 ` [RFC PATCH 2/2] iommu: Add IOMMU_UNBIND_FAULT_PENDING flag Jean-Philippe Brucker
2020-10-16 7:07 ` Christoph Hellwig
2020-10-15 18:22 ` [RFC PATCH 0/2] iommu: Avoid unnecessary PRI queue flushes Raj, Ashok
2020-10-16 7:59 ` Jean-Philippe Brucker
2020-10-17 11:25 ` Raj, Ashok
2020-10-19 14:08 ` Jean-Philippe Brucker
2020-10-19 18:33 ` Jacob Pan
2020-10-23 13:30 ` Jean-Philippe Brucker
2020-10-19 21:16 ` Raj, Ashok
2020-10-23 13:34 ` Jean-Philippe Brucker
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=20201015090028.1278108-1-jean-philippe@linaro.org \
--to=jean-philippe@linaro.org \
--cc=arnd@arndb.de \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-accelerators@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=wangzhou1@hisilicon.com \
--cc=zhangfei.gao@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).