From: Eric Auger <eric.auger@redhat.com>
To: eric.auger.pro@gmail.com, eric.auger@redhat.com,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
peter.maydell@linaro.org, peterx@redhat.com
Cc: jean-philippe@linaro.org, robh@kernel.org, robin.murphy@arm.com,
mst@redhat.com, zhangfei.gao@foxmail.com,
shameerali.kolothum.thodi@huawei.com, will@kernel.org
Subject: [PATCH for-5.2 v4 00/11] SMMUv3.2 Range-based TLB Invalidation Support
Date: Tue, 28 Jul 2020 17:08:04 +0200 [thread overview]
Message-ID: <20200728150815.11446-1-eric.auger@redhat.com> (raw)
SMMU3.2 brings the support of range-based TLB invalidation and
level hint. When this feature is supported, the SMMUv3 driver
is allowed to send TLB invalidations for a range of IOVAs instead
of using page based invalidation.
Implementing this feature in the virtual SMMUv3 device is
mandated for DPDK on guest use case: DPDK uses hugepage
buffers and guest sends invalidations for blocks. Without
this feature, a guest invalidation of a block of 1GB for instance
translates into a storm of page invalidations. Each of them
is trapped by the VMM and cascaded downto the physical IOMMU.
This completely stalls the execution. This integration issue
was initially reported in [1].
Now SMMUv3.2 specifies additional parameters to NH_VA and NH_VAA
stage 1 invalidation commands so we can support those extensions.
Supporting block mappings in the IOTLB look sensible in terms of
TLB entry consumption. However looking at virtio/vhost device usage,
without block mapping and without range invalidation (< 5.7 kernels
it may be less performant. However for recent guest kernels
supporting range invalidations [2], the performance should be similar.
Best Regards
Eric
This series can be found at:
https://github.com/eauger/qemu.git
branch: v5.1.0-rc1-smmuv3-ril-v4
References:
[1] [RFC v2 4/4] iommu/arm-smmu-v3: add CMD_TLBI_NH_VA_AM command
for iova range invalidation
(https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023679.html
[2] 5.7+ kernels featuring
6a481a95d4c1 iommu/arm-smmu-v3: Add SMMUv3.2 range invalidation support
History:
v3 -> v4:
- use tg in hash function and directly compare key fields in the
equal function
- don't claim 3.2 as we don't have BBML support yet
- fixed a bunch of indent issues
v2 -> v3:
- restore the Jenkins hash function and keep the key as a struct
- simplify the logic in smmu_hash_remove_by_asid_iova
- added HAD support
- expose AIDR (advertise v3.2 support) and fix IIDR offset
v1 -> v2:
- added "hw/arm/smmu: Introduce smmu_get_iotlb_key()"
- removed "[PATCH 5/9] hw/arm/smmuv3: Store the starting level in
SMMUTransTableInfo"
- Collected Peter's R-b
- In this version the key still features TG/LVL.
- More details in individual history logs
Eric Auger (11):
hw/arm/smmu-common: Factorize some code in smmu_ptw_64()
hw/arm/smmu-common: Add IOTLB helpers
hw/arm/smmu: Introduce smmu_get_iotlb_key()
hw/arm/smmu: Introduce SMMUTLBEntry for PTW and IOTLB value
hw/arm/smmu-common: Manage IOTLB block entries
hw/arm/smmuv3: Introduce smmuv3_s1_range_inval() helper
hw/arm/smmuv3: Get prepared for range invalidation
hw/arm/smmuv3: Fix IIDR offset
hw/arm/smmuv3: Let AIDR advertise SMMUv3.0 support
hw/arm/smmuv3: Support HAD and advertise SMMUv3.1 support
hw/arm/smmuv3: Advertise SMMUv3.2 range invalidation
hw/arm/smmu-internal.h | 8 ++
hw/arm/smmuv3-internal.h | 10 +-
include/hw/arm/smmu-common.h | 19 +++-
include/hw/arm/smmuv3.h | 1 +
hw/arm/smmu-common.c | 214 ++++++++++++++++++++++++-----------
hw/arm/smmuv3.c | 142 +++++++++++------------
hw/arm/trace-events | 12 +-
7 files changed, 258 insertions(+), 148 deletions(-)
--
2.21.3
next reply other threads:[~2020-07-28 15:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 15:08 Eric Auger [this message]
2020-07-28 15:08 ` [PATCH for-5.2 v4 01/11] hw/arm/smmu-common: Factorize some code in smmu_ptw_64() Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 02/11] hw/arm/smmu-common: Add IOTLB helpers Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 03/11] hw/arm/smmu: Introduce smmu_get_iotlb_key() Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 04/11] hw/arm/smmu: Introduce SMMUTLBEntry for PTW and IOTLB value Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 05/11] hw/arm/smmu-common: Manage IOTLB block entries Eric Auger
2020-07-30 13:38 ` Peter Maydell
2020-07-31 9:35 ` Auger Eric
2020-07-28 15:08 ` [PATCH for-5.2 v4 06/11] hw/arm/smmuv3: Introduce smmuv3_s1_range_inval() helper Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 07/11] hw/arm/smmuv3: Get prepared for range invalidation Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 08/11] hw/arm/smmuv3: Fix IIDR offset Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 09/11] hw/arm/smmuv3: Let AIDR advertise SMMUv3.0 support Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 10/11] hw/arm/smmuv3: Support HAD and advertise SMMUv3.1 support Eric Auger
2020-07-28 15:08 ` [PATCH for-5.2 v4 11/11] hw/arm/smmuv3: Advertise SMMUv3.2 range invalidation Eric Auger
2020-07-30 13:39 ` [PATCH for-5.2 v4 00/11] SMMUv3.2 Range-based TLB Invalidation Support Peter Maydell
2020-08-06 12:55 ` Peter Maydell
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=20200728150815.11446-1-eric.auger@redhat.com \
--to=eric.auger@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=jean-philippe@linaro.org \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=will@kernel.org \
--cc=zhangfei.gao@foxmail.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.