Re: [PATCH RFC v1 2/6] swiotlb: convert variables to arrays
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote: > This patch converts several swiotlb related variables to arrays, in > order to maintain stat/status for different swiotlb buffers. Here are > variables involved: > > - io_tlb_start and io_tlb_end > - io_tlb_nslabs and io_tlb_used > - io_tlb_list > - io_tlb_index > - max_segment > - io_tlb_orig_addr > - no_iotlb_memory > > There is no functional change and this is to prepare to enable 64-bit > swiotlb. Claire Chang (on Cc) already posted a patch like this a month ago, which looks much better because it actually uses a struct instead of all the random variables. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 2/2] iommu: add Unisoc IOMMU basic driver
From: Chunyan Zhang
This IOMMU module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
Signed-off-by: Chunyan Zhang
---
drivers/iommu/Kconfig | 12 +
drivers/iommu/Makefile | 1 +
drivers/iommu/sprd-iommu.c | 599 +
3 files changed, 612 insertions(+)
create mode 100644 drivers/iommu/sprd-iommu.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 192ef8f61310..2ef0b3918440 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -408,4 +408,16 @@ config VIRTIO_IOMMU
Say Y here if you intend to run this kernel as a guest.
+config SPRD_IOMMU
+ tristate "Unisoc IOMMU Support"
+ depends on ARCH_SPRD || COMPILE_TEST
+ select IOMMU_API
+ help
+ Support for IOMMU on Unisoc's SoCs, this IOMMU can be used by
+ Unisoc's multimedia devices, such as display, Image codec(jpeg)
+ and a few signal processors, including VSP(video), GSP(graphic),
+ ISP(image), and CPP(camera pixel processor), etc.
+
+ Say Y here if you want to use the multimedia devices listed above.
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 61bd30cd8369..5925b6af2123 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
obj-$(CONFIG_IOMMU_SVA_LIB) += iommu-sva-lib.o
+obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
new file mode 100644
index ..022fe62027c0
--- /dev/null
+++ b/drivers/iommu/sprd-iommu.c
@@ -0,0 +1,599 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Unisoc IOMMU driver
+ *
+ * Copyright (C) 2020 Unisoc, Inc.
+ * Author: Chunyan Zhang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SPRD_IOMMU_PAGE_SHIFT 12
+#define SPRD_IOMMU_PAGE_SIZE SZ_4K
+
+#define SPRD_EX_CFG0x0
+#define SPRD_IOMMU_VAOR_BYPASS BIT(4)
+#define SPRD_IOMMU_GATE_EN BIT(1)
+#define SPRD_IOMMU_EN BIT(0)
+#define SPRD_EX_UPDATE 0x4
+#define SPRD_EX_FIRST_VPN 0x8
+#define SPRD_EX_VPN_RANGE 0xc
+#define SPRD_EX_FIRST_PPN 0x10
+#define SPRD_EX_DEFAULT_PPN0x14
+
+#define SPRD_IOMMU_VERSION 0x0
+#define SPRD_VERSION_MASK GENMASK(15, 8)
+#define SPRD_VERSION_SHIFT 0x8
+#define SPRD_VAU_CFG 0x4
+#define SPRD_VAU_UPDATE0x8
+#define SPRD_VAU_AUTH_CFG 0xc
+#define SPRD_VAU_FIRST_PPN 0x10
+#define SPRD_VAU_DEFAULT_PPN_RD0x14
+#define SPRD_VAU_DEFAULT_PPN_WR0x18
+#define SPRD_VAU_FIRST_VPN 0x1c
+#define SPRD_VAU_VPN_RANGE 0x20
+
+enum sprd_iommu_version {
+ SPRD_IOMMU_EX,
+ SPRD_IOMMU_VAU,
+};
+
+/*
+ * struct sprd_iommu_device - high-level sprd IOMMU device representation,
+ * including hardware information and configuration, also driver data, etc
+ *
+ * @ver: sprd IOMMU IP version
+ * @prot_page_va: protect page base virtual address
+ * @prot_page_pa: protect page base physical address, data would be
+ * written to here while translation fault
+ * @base: mapped base address for accessing registers
+ * @reg_offset: some IOMMU shares the same range of registers with the
multimedia
+ * device which use it, this represents the IOMMU register offset
+ * @dev: pointer to basic device structure
+ * @iommu: IOMMU core representation
+ * @group: IOMMU group
+ * @eb: gate clock which controls IOMMU access
+ */
+struct sprd_iommu_device {
+ enum sprd_iommu_version ver;
+ u32 *prot_page_va;
+ dma_addr_t prot_page_pa;
+ struct regmap *base;
+ unsigned intreg_offset;
+ struct device *dev;
+ struct iommu_device iommu;
+ struct iommu_group *group;
+ struct clk *eb;
+};
+
+struct sprd_iommu_domain {
+ spinlock_t pgtlock; /* lock for page table */
+ struct iommu_domain domain;
+ u32 *pgt_va; /* page table virtual address base */
+ dma_addr_t pgt_pa; /* page table physical address base */
+ struct sprd_iommu_device*sdev;
+};
+
+static const struct iommu_ops sprd_iommu_ops;
+
+static struct sprd_iommu_domain *to_sprd_domain(struct iommu_domain *dom)
+{
+ return container_of(dom, struct sprd_iommu_domain, domain);
+}
+
+static inline void
+sprd_iommu_write(struct sprd_iommu_device *sdev, unsigned int reg, u32 val)
+{
+ regmap_write(sdev->base, sdev->reg_offset + reg, val);
+}
+
+static inline u32
+sprd_iommu_read(struct sprd_iommu_device
[PATCH v4 1/2] dt-bindings: iommu: add bindings for sprd IOMMU
From: Chunyan Zhang
This IOMMU module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
Signed-off-by: Chunyan Zhang
---
.../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
new file mode 100644
index ..36abd2187a19
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2020 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc IOMMU and Multi-media MMU
+
+maintainers:
+ - Chunyan Zhang
+
+properties:
+ compatible:
+enum:
+ - sprd,iommu-v1
+
+ "#iommu-cells":
+const: 0
+description:
+ Unisoc IOMMUs are all single-master IOMMU devices, therefore no
+ additional information needs to associate with its master device.
+ Please refer to the generic bindings document for more details,
+ Documentation/devicetree/bindings/iommu/iommu.txt
+
+ reg:
+maxItems: 1
+description:
+ Not required if 'sprd,iommu-regs' is defined.
+
+ clocks:
+description:
+ Reference to a gate clock phandle, since access to some of IOMMUs are
+ controlled by gate clock, but this is not required.
+
+ sprd,iommu-regs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+ Reference to a syscon phandle plus 1 cell, the syscon defines the
+ register range used by IOMMU and multimedia device, the cell
+ defines the offset for IOMMU registers. Since IOMMU module shares
+ the same register range with the multimedia device which uses it.
+
+required:
+ - compatible
+ - "#iommu-cells"
+
+oneOf:
+ - required:
+ - reg
+ - required:
+ - sprd,iommu-regs
+
+additionalProperties: false
+
+examples:
+ - |
+iommu_disp: iommu-disp {
+ compatible = "sprd,iommu-v1";
+ sprd,iommu-regs = <&dpu_regs 0x800>;
+ #iommu-cells = <0>;
+};
+
+ - |
+iommu_jpg: iommu-jpg {
+ compatible = "sprd,iommu-v1";
+ sprd,iommu-regs = <&jpg_regs 0x300>;
+ #iommu-cells = <0>;
+ clocks = <&mm_gate 1>;
+};
+
+...
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 0/2] Add Unisoc IOMMU basic driver
From: Chunyan Zhang Changes since v3: * Rebased on iommu/next, and fixed compile error reported by kernel test robot ; * %s/iommu/IOMMU/ properly in the whole patchset. Changes since v2: * Added a WARN and return 0 if an invalid iova was passed to sprd_iommu_iova_to_phys(); * Changed the name of sprd_iommu_write(); * Revised CONFIG_SPRD_IOMMU help graph in Kconfig. * Revised comments for the struct sprd_iommu_device; * Converted to use "GPL" instread of "GPL v2", they are same as license-rules.rst shows. Changes since v1: * Fixed compile errors reported by kernel test robot . * Changed to use syscon to get mapped registers for iommu and media devices to avoid double map issue. * Addressed Robin's comments: - Added including offset in the returned physical address if the input virtual address isn't page-aligned; - Added platform_device_put() after calling of_find_device_by_node(); - Removed iommu register offset from driver, it will be defined as the cell of DT reference to syscon phandle; - Removed multi compatible strings which are not needed; - Added comments for the function sprd_iommu_clk_enable(); - Added clocks property in bindings; - Set device_driver.suppress_bind_attrs to disable unbind the devices via sysfs; - A few trivial fixes. Changes since RFC v2: * Addressed Robin's comments: - Add COMPILE_TEST support; - Use DMA allocator for PTE; - Revised to avoid resource leak issue; - Added ->iotlb_sync implemented; - Moved iommu group allocation to probe; - Changed some function names to make them sprd specific; * Added support for more iommu instance; Changes since RFC v1: * Rebased on v5.11-rc1; * Changed sprd-iommu to tristate; * Removed check for args_count of iommu OF node, since there's no args for sprd-iommu device node; * Added another IP version (i.e. vau); * Removed unnecessary configs selection from CONFIG_SPRD_IOMMU; * Changed to get zeroed pages. Chunyan Zhang (2): dt-bindings: iommu: add bindings for sprd IOMMU iommu: add Unisoc IOMMU basic driver .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++ drivers/iommu/Kconfig | 12 + drivers/iommu/Makefile| 1 + drivers/iommu/sprd-iommu.c| 599 ++ 4 files changed, 684 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml create mode 100644 drivers/iommu/sprd-iommu.c -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 3/3] dma-contiguous: Type cast MAX_ORDER as unsigned int
Type cast MAX_ORDER as unsigned int to fix the following build warning.
In file included from ./include/linux/kernel.h:14,
from ./include/asm-generic/bug.h:20,
from ./arch/arm64/include/asm/bug.h:26,
from ./include/linux/bug.h:5,
from ./include/linux/mmdebug.h:5,
from ./arch/arm64/include/asm/memory.h:166,
from ./arch/arm64/include/asm/page.h:42,
from kernel/dma/contiguous.c:46:
kernel/dma/contiguous.c: In function ‘rmem_cma_setup’:
./include/linux/minmax.h:18:28: warning: comparison of distinct pointer
types lacks a cast
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^~
./include/linux/minmax.h:32:4: note: in expansion of macro ‘__typecheck’
(__typecheck(x, y) && __no_side_effects(x, y))
^~~
./include/linux/minmax.h:42:24: note: in expansion of macro ‘__safe_cmp’
__builtin_choose_expr(__safe_cmp(x, y), \
^~
./include/linux/minmax.h:58:19: note: in expansion of macro
‘__careful_cmp’
#define max(x, y) __careful_cmp(x, y, >)
^
kernel/dma/contiguous.c:402:35: note: in expansion of macro ‘max’
phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
kernel/dma/contiguous.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 3d63d91cba5c..1c2782349d71 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = {
static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
- phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+ phys_addr_t align = PAGE_SIZE << max((unsigned int)MAX_ORDER - 1,
pageblock_order);
phys_addr_t mask = align - 1;
unsigned long node = rmem->fdt_node;
bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
--
2.20.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 2/3] arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE
MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can be greater than MAX_ORDER, making it unusable as pageblock_order. This enables HUGETLB_PAGE_SIZE_VARIABLE making pageblock_order a variable rather than the compile time constant HUGETLB_PAGE_ORDER which could break MAX_ORDER rule for certain configurations. Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Anshuman Khandual --- arch/arm64/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 175914f2f340..c4acf8230f20 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1918,6 +1918,10 @@ config ARCH_ENABLE_THP_MIGRATION def_bool y depends on TRANSPARENT_HUGEPAGE +config HUGETLB_PAGE_SIZE_VARIABLE + def_bool y + depends on HUGETLB_PAGE + menu "Power management options" source "kernel/power/Kconfig" -- 2.20.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 1/3] mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER
With HUGETLB_PAGE_SIZE_VARIABLE enabled, pageblock_order cannot be assigned as HUGETLB_PAGE_ORDER when it is greater than or equal to MAX_ORDER during set_pageblock_order(). Otherwise the following warning is triggered during boot as detected on an arm64 platform. WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0 Modules linked in: CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159 Hardware name: linux,dummy-virt (DT) [8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--) [8.811732] pc : __fragmentation_index+0xa4/0xc0 [8.812555] lr : fragmentation_index+0xf8/0x138 [8.813360] sp : 864079b0 [8.813958] x29: 864079b0 x28: 0372 [8.814901] x27: 7682 x26: 8000135b3948 [8.815847] x25: 1fffe00010c80f48 x24: [8.816805] x23: x22: 000d [8.817764] x21: 0030 x20: 0005ffcb4d58 [8.818712] x19: 000b x18: [8.819656] x17: x16: [8.820613] x15: x14: 8000114c6258 [8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9 [8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9 [8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf [8.824415] x7 : 0001 x6 : 41b58ab3 [8.825359] x5 : 600010c80f48 x4 : dfff8000 [8.826313] x3 : 8000102be670 x2 : 0007 [8.827259] x1 : 86407a60 x0 : 000d [8.828218] Call trace: [8.828667] __fragmentation_index+0xa4/0xc0 [8.829436] fragmentation_index+0xf8/0x138 [8.830194] compaction_suitable+0x98/0xb8 [8.830934] wakeup_kcompactd+0xdc/0x128 [8.831640] balance_pgdat+0x71c/0x7a0 [8.832327] kswapd+0x31c/0x520 [8.832902] kthread+0x224/0x230 [8.833491] ret_from_fork+0x10/0x30 [8.834150] ---[ end trace 472836f79c15516b ]--- The above warning happens because pageblock_order exceeds MAX_ORDER, caused by large HUGETLB_PAGE_ORDER on certain platforms like arm64. Lets prevent the scenario by first checking HUGETLB_PAGE_ORDER against MAX_ORDER, before its assignment as pageblock_order. Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Anshuman Khandual --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 519a60d5b6f7..36473f2fa683 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6798,7 +6798,7 @@ void __init set_pageblock_order(void) if (pageblock_order) return; - if (HPAGE_SHIFT > PAGE_SHIFT) + if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER)) order = HUGETLB_PAGE_ORDER; else order = MAX_ORDER - 1; -- 2.20.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE
The following warning gets triggered while trying to boot a 64K page size
without THP config kernel on arm64 platform.
WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0
Modules linked in:
CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159
Hardware name: linux,dummy-virt (DT)
[8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--)
[8.811732] pc : __fragmentation_index+0xa4/0xc0
[8.812555] lr : fragmentation_index+0xf8/0x138
[8.813360] sp : 864079b0
[8.813958] x29: 864079b0 x28: 0372
[8.814901] x27: 7682 x26: 8000135b3948
[8.815847] x25: 1fffe00010c80f48 x24:
[8.816805] x23: x22: 000d
[8.817764] x21: 0030 x20: 0005ffcb4d58
[8.818712] x19: 000b x18:
[8.819656] x17: x16:
[8.820613] x15: x14: 8000114c6258
[8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9
[8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9
[8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf
[8.824415] x7 : 0001 x6 : 41b58ab3
[8.825359] x5 : 600010c80f48 x4 : dfff8000
[8.826313] x3 : 8000102be670 x2 : 0007
[8.827259] x1 : 86407a60 x0 : 000d
[8.828218] Call trace:
[8.828667] __fragmentation_index+0xa4/0xc0
[8.829436] fragmentation_index+0xf8/0x138
[8.830194] compaction_suitable+0x98/0xb8
[8.830934] wakeup_kcompactd+0xdc/0x128
[8.831640] balance_pgdat+0x71c/0x7a0
[8.832327] kswapd+0x31c/0x520
[8.832902] kthread+0x224/0x230
[8.833491] ret_from_fork+0x10/0x30
[8.834150] ---[ end trace 472836f79c15516b ]---
This warning comes from __fragmentation_index() when the requested order
is greater than MAX_ORDER.
static int __fragmentation_index(unsigned int order,
struct contig_page_info *info)
{
unsigned long requested = 1UL << order;
if (WARN_ON_ONCE(order >= MAX_ORDER)) <= Triggered here
return 0;
Digging it further reveals that pageblock_order has been assigned a value
which is greater than MAX_ORDER failing the above check. But why this
happened ? Because HUGETLB_PAGE_ORDER for the given config on arm64 is
greater than MAX_ORDER.
The solution involves enabling HUGETLB_PAGE_SIZE_VARIABLE which would make
pageblock_order a variable instead of constant HUGETLB_PAGE_ORDER. But that
change alone also did not really work as pageblock_order still got assigned
as HUGETLB_PAGE_ORDER in set_pageblock_order(). HUGETLB_PAGE_ORDER needs to
be less than MAX_ORDER for its appropriateness as pageblock_order otherwise
just fallback to MAX_ORDER - 1 as before. While here it also fixes a build
problem via type casting MAX_ORDER in rmem_cma_setup().
This series applies in v5.11-rc6 and has been slightly tested on arm64. But
looking for some early feedbacks particularly with respect to concerns in
subscribing HUGETLB_PAGE_SIZE_VARIABLE on a platform where the hugetlb page
size is config dependent but not really a runtime variable. Even though it
appears that HUGETLB_PAGE_SIZE_VARIABLE is used only while computing the
pageblock_order, could there be other implications ?
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Robin Murphy
Cc: Marek Szyprowski
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: linux-arm-ker...@lists.infradead.org
Cc: iommu@lists.linux-foundation.org
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Anshuman Khandual (3):
mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER
arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE
dma-contiguous: Type cast MAX_ORDER as unsigned int
arch/arm64/Kconfig | 4
kernel/dma/contiguous.c | 2 +-
mm/page_alloc.c | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
--
2.20.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: Unable to read/write to IOMMU perf counter
On 02/02/2021 05:54, Suravee Suthikulpanit wrote: > Could you please try the attached patch to see if the problem still > persist. Tested on top of commit 61556703b610 doesn't appear to have solved the issue. Linux version 5.11.0-rc6+ (tj@elloe000) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubunt> Command line: BOOT_IMAGE=/vmlinuz-5.11.0-rc6+ root=/dev/mapper/ELLOE000-rootfs ro acpi_osi=! "acpi_osi=Windows 20> ... DMI: LENOVO 20NECTO1WW/20NECTO1WW, BIOS R11ET32W (1.12 ) 12/23/2019 ... AMD-Vi: ivrs, add hid:PNPD0040, uid:, rdevid:152 ... smpboot: CPU0: AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx (family: 0x17, model: 0x18, stepping: 0x1) ... pci :00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter. pci :00:00.2: can't derive routing for PCI INT A pci :00:00.2: PCI INT A: not connected pci :00:01.0: Adding to iommu group 0 pci :00:01.1: Adding to iommu group 1 ... pci :00:00.2: AMD-Vi: Found IOMMU cap 0x40 pci :00:00.2: AMD-Vi: Extended features (0x4f77ef22294ada): PPR NX GT IA GA PC GA_vAPIC AMD-Vi: Interrupt remapping enabled AMD-Vi: Virtual APIC enabled AMD-Vi: Lazy IO/TLB flushing enabled amd_uncore: 4 amd_df counters detected ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/7] [PULL REQUEST] iommu/vt-d: Update for v5.12
Hi Joerg, I just received some internal comments on the last patch [PATCH 7/7] iommu/vt-d: Apply SATC policy We need some extra work on it and probably re-target it to v5.13. Can you please only consider patch 1 ~ 6 for v5.12? Sorry for the inconvenience. Best regards, baolu On 2/4/21 9:43 AM, Lu Baolu wrote: Hi Joerg, The patches queued in this series is for v5.12. It includes: - Audit capability consistency among different IOMMUs - Add SATC reporting structure support - Add iotlb_sync_map callback support - Misc cleanup Please consider them for v5.12. Best regards, Lu Baolu Bjorn Helgaas (1): iommu/vt-d: Fix 'physical' typos Kyung Min Park (2): iommu/vt-d: Audit IOMMU Capabilities and add helper functions iommu/vt-d: Move capability check code to cap_audit files Lu Baolu (1): iommu/vt-d: Add iotlb_sync_map callback Yian Chen (3): iommu/vt-d: Add new enum value and structure for SATC iommu/vt-d: Parse SATC reporting structure iommu/vt-d: Apply SATC policy drivers/iommu/intel/Makefile| 2 +- drivers/iommu/intel/cap_audit.c | 205 + drivers/iommu/intel/cap_audit.h | 130 +++ drivers/iommu/intel/dmar.c | 8 + drivers/iommu/intel/iommu.c | 337 +++- drivers/iommu/intel/irq_remapping.c | 8 + include/acpi/actbl1.h | 11 +- include/linux/dmar.h| 2 + include/linux/intel-iommu.h | 41 ++-- 9 files changed, 615 insertions(+), 129 deletions(-) create mode 100644 drivers/iommu/intel/cap_audit.c create mode 100644 drivers/iommu/intel/cap_audit.h ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 2/2] iommu: add Unisoc iommu basic driver
On Thu, 4 Feb 2021 at 01:44, Randy Dunlap wrote: > > On 2/3/21 1:07 AM, Chunyan Zhang wrote: > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index 192ef8f61310..99e7712f3903 100644 > > --- a/drivers/iommu/Kconfig > > +++ b/drivers/iommu/Kconfig > > @@ -408,4 +408,16 @@ config VIRTIO_IOMMU > > > > Say Y here if you intend to run this kernel as a guest. > > > > +config SPRD_IOMMU > > + tristate "Unisoc IOMMU Support" > > + depends on ARCH_SPRD || COMPILE_TEST > > + select IOMMU_API > > + help > > + Support for IOMMU on Unisoc's SoCs, this iommu can be used by > > s/iommu/IOMMU/ please Sure, thanks. Chunyan > > > + Unisoc's multimedia devices, such as display, Image codec(jpeg) > > + and a few signal processors, including VSP(video), GSP(graphic), > > + ISP(image), and CPP(camera pixel processor), etc. > > + > > + Say Y here if you want to use the multimedia devices listed above. > > > -- > ~Randy ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 3/3] iommu/vt-d: Apply SATC policy
Hi Kevin, On 2/4/21 9:59 AM, Tian, Kevin wrote: From: Lu Baolu Sent: Wednesday, February 3, 2021 5:33 PM From: Yian Chen Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC table structure. SATC table lists a set of SoC integrated devices that require ATC to work (VT-d specification v3.2, section 8.8). Furthermore, This statement is not accurate. The purpose of SATC is to tell whether a SoC integrated device has been validated to meet the isolation requirements of using device TLB. All devices listed in SATC can have ATC safely enabled by OS. In addition, there is a flag for each listed device for whether ATC is a functional requirement. However, above description only captured the last point. You are right. This series only addresses the devices with the flag set which have functional requirement for ATS. the new version of IOMMU supports SoC device ATS in both its Scalable mode and legacy mode. When IOMMU is working in scalable mode, software must enable device ATS support. "must enable" is misleading here. You need describe the policies for three categories: - SATC devices with ATC_REQUIRED=1 - SATC devices with ATC_REQUIRED=0 - devices not listed in SATC, or when SATC is missing Yian is working on this part. We planed it for v5.13. He will bring it up for discussion later. On the other hand, when IOMMU is in legacy mode for whatever reason, the hardware managed ATS will automatically take effect and the SATC required devices can work transparently to the software. As the No background about hardware-managed ATS. result, software shouldn't enable ATS on that device, otherwise duplicate device TLB invalidations will occur. This description draws a equation between legacy mode and hardware managed ATS. Do we care about the scenario where there is no hardware managed ATS but people also want to turn on ATC in legacy mode? The hardware managed ATS is defined in the platform specific specification. The purpose of this hardware design is backward compatibility - legacy OSes with no SM or ATS awareness still running well on them. Thanks Kevin Best regards, baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v2 3/3] iommu/vt-d: Apply SATC policy
> From: Lu Baolu
> Sent: Wednesday, February 3, 2021 5:33 PM
>
> From: Yian Chen
>
> Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
> table structure. SATC table lists a set of SoC integrated devices that
> require ATC to work (VT-d specification v3.2, section 8.8). Furthermore,
This statement is not accurate. The purpose of SATC is to tell whether a
SoC integrated device has been validated to meet the isolation requirements
of using device TLB. All devices listed in SATC can have ATC safely enabled by
OS. In addition, there is a flag for each listed device for whether ATC is a
functional requirement. However, above description only captured the last
point.
> the new version of IOMMU supports SoC device ATS in both its Scalable
> mode
> and legacy mode.
>
> When IOMMU is working in scalable mode, software must enable device ATS
> support.
"must enable" is misleading here. You need describe the policies for three
categories:
- SATC devices with ATC_REQUIRED=1
- SATC devices with ATC_REQUIRED=0
- devices not listed in SATC, or when SATC is missing
> On the other hand, when IOMMU is in legacy mode for whatever
> reason, the hardware managed ATS will automatically take effect and the
> SATC required devices can work transparently to the software. As the
No background about hardware-managed ATS.
> result, software shouldn't enable ATS on that device, otherwise duplicate
> device TLB invalidations will occur.
This description draws a equation between legacy mode and hardware
managed ATS. Do we care about the scenario where there is no hardware
managed ATS but people also want to turn on ATC in legacy mode?
Thanks
Kevin
>
> Signed-off-by: Yian Chen
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 73
> +++--
> 1 file changed, 69 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index ee0932307d64..3e30c340e6a9 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -872,6 +872,60 @@ static bool iommu_is_dummy(struct intel_iommu
> *iommu, struct device *dev)
> return false;
> }
>
> +static bool iommu_support_ats(struct intel_iommu *iommu)
> +{
> + return ecap_dev_iotlb_support(iommu->ecap);
> +}
> +
> +static bool device_support_ats(struct pci_dev *dev)
> +{
> + return pci_ats_supported(dev) &&
> dmar_find_matched_atsr_unit(dev);
> +}
> +
> +static int segment_atc_required(u16 segment)
> +{
> + struct acpi_dmar_satc *satc;
> + struct dmar_satc_unit *satcu;
> + int ret = 1;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(satcu, &dmar_satc_units, list) {
> + satc = container_of(satcu->hdr, struct acpi_dmar_satc,
> header);
> + if (satcu->atc_required && satcu->devices_cnt &&
> + satc->segment == segment)
> + goto out;
> + }
> + ret = 0;
> +out:
> + rcu_read_unlock();
> + return ret;
> +}
> +
> +static int device_atc_required(struct pci_dev *dev)
> +{
> + struct dmar_satc_unit *satcu;
> + struct acpi_dmar_satc *satc;
> + struct device *tmp;
> + int i, ret = 1;
> +
> + dev = pci_physfn(dev);
> + rcu_read_lock();
> + list_for_each_entry_rcu(satcu, &dmar_satc_units, list) {
> + satc = container_of(satcu->hdr, struct acpi_dmar_satc,
> header);
> + if (!satcu->atc_required ||
> + satc->segment != pci_domain_nr(dev->bus))
> + continue;
> +
> + for_each_dev_scope(satcu->devices, satcu->devices_cnt, i,
> tmp)
> + if (to_pci_dev(tmp) == dev)
> + goto out;
> + }
> + ret = 0;
> +out:
> + rcu_read_unlock();
> + return ret;
> +}
> +
> struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8
> *devfn)
> {
> struct dmar_drhd_unit *drhd = NULL;
> @@ -2555,10 +2609,16 @@ static struct dmar_domain
> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> if (dev && dev_is_pci(dev)) {
> struct pci_dev *pdev = to_pci_dev(info->dev);
>
> - if (ecap_dev_iotlb_support(iommu->ecap) &&
> - pci_ats_supported(pdev) &&
> - dmar_find_matched_atsr_unit(pdev))
> - info->ats_supported = 1;
> + /*
> + * Support ATS by default if it's supported by both IOMMU
> and
> + * client sides, except that the device's ATS is required by
> + * ACPI/SATC but the IOMMU scalable mode is disabled. In
> that
> + * case the hardware managed ATS will be automatically used.
> + */
> + if (iommu_support_ats(iommu) &&
> device_support_ats(pdev)) {
> + if (!device_atc_required(pdev) ||
> sm_supported(iommu))
> + info->ats_supported = 1;
> + }
>
> if (sm_
[PATCH 7/7] iommu/vt-d: Apply SATC policy
From: Yian Chen
Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
table structure. SATC table lists a set of SoC integrated devices that
require ATC to work (VT-d specification v3.2, section 8.8). Furthermore,
the new version of IOMMU supports SoC device ATS in both its Scalable mode
and legacy mode.
When IOMMU is working in scalable mode, software must enable device ATS
support. On the other hand, when IOMMU is in legacy mode for whatever
reason, the hardware managed ATS will automatically take effect and the
SATC required devices can work transparently to the software. As the
result, software shouldn't enable ATS on that device, otherwise duplicate
device TLB invalidations will occur.
Signed-off-by: Yian Chen
Link:
https://lore.kernel.org/r/20210203093329.1617808-1-baolu...@linux.intel.com
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 73 +++--
1 file changed, 69 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee0932307d64..3e30c340e6a9 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -872,6 +872,60 @@ static bool iommu_is_dummy(struct intel_iommu *iommu,
struct device *dev)
return false;
}
+static bool iommu_support_ats(struct intel_iommu *iommu)
+{
+ return ecap_dev_iotlb_support(iommu->ecap);
+}
+
+static bool device_support_ats(struct pci_dev *dev)
+{
+ return pci_ats_supported(dev) && dmar_find_matched_atsr_unit(dev);
+}
+
+static int segment_atc_required(u16 segment)
+{
+ struct acpi_dmar_satc *satc;
+ struct dmar_satc_unit *satcu;
+ int ret = 1;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(satcu, &dmar_satc_units, list) {
+ satc = container_of(satcu->hdr, struct acpi_dmar_satc, header);
+ if (satcu->atc_required && satcu->devices_cnt &&
+ satc->segment == segment)
+ goto out;
+ }
+ ret = 0;
+out:
+ rcu_read_unlock();
+ return ret;
+}
+
+static int device_atc_required(struct pci_dev *dev)
+{
+ struct dmar_satc_unit *satcu;
+ struct acpi_dmar_satc *satc;
+ struct device *tmp;
+ int i, ret = 1;
+
+ dev = pci_physfn(dev);
+ rcu_read_lock();
+ list_for_each_entry_rcu(satcu, &dmar_satc_units, list) {
+ satc = container_of(satcu->hdr, struct acpi_dmar_satc, header);
+ if (!satcu->atc_required ||
+ satc->segment != pci_domain_nr(dev->bus))
+ continue;
+
+ for_each_dev_scope(satcu->devices, satcu->devices_cnt, i, tmp)
+ if (to_pci_dev(tmp) == dev)
+ goto out;
+ }
+ ret = 0;
+out:
+ rcu_read_unlock();
+ return ret;
+}
+
struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devfn)
{
struct dmar_drhd_unit *drhd = NULL;
@@ -2555,10 +2609,16 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
if (dev && dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(info->dev);
- if (ecap_dev_iotlb_support(iommu->ecap) &&
- pci_ats_supported(pdev) &&
- dmar_find_matched_atsr_unit(pdev))
- info->ats_supported = 1;
+ /*
+* Support ATS by default if it's supported by both IOMMU and
+* client sides, except that the device's ATS is required by
+* ACPI/SATC but the IOMMU scalable mode is disabled. In that
+* case the hardware managed ATS will be automatically used.
+*/
+ if (iommu_support_ats(iommu) && device_support_ats(pdev)) {
+ if (!device_atc_required(pdev) || sm_supported(iommu))
+ info->ats_supported = 1;
+ }
if (sm_supported(iommu)) {
if (pasid_supported(iommu)) {
@@ -3155,6 +3215,11 @@ static int __init init_dmars(void)
* endfor
*/
for_each_drhd_unit(drhd) {
+ if (pci_ats_disabled() && segment_atc_required(drhd->segment)) {
+ pr_warn("Scalable mode disabled -- Use hardware managed
ATS because PCIe ATS is disabled but some devices in PCIe segment 0x%x require
it.",
+ drhd->segment);
+ intel_iommu_sm = 0;
+ }
/*
* lock not needed as this is only incremented in the single
* threaded kernel __init code path all other access are read
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 6/7] iommu/vt-d: Parse SATC reporting structure
From: Yian Chen
Software should parse every SATC table and all devices in the tables
reported by the BIOS and keep the information in kernel list for further
reference.
Signed-off-by: Yian Chen
Link:
https://lore.kernel.org/r/20210203093329.1617808-1-baolu...@linux.intel.com
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/dmar.c | 8
drivers/iommu/intel/iommu.c | 89 +
include/linux/dmar.h| 2 +
3 files changed, 99 insertions(+)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 980e8ae090af..d5c51b5c20af 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -526,6 +526,7 @@ dmar_table_print_dmar_entry(struct acpi_dmar_header *header)
struct acpi_dmar_reserved_memory *rmrr;
struct acpi_dmar_atsr *atsr;
struct acpi_dmar_rhsa *rhsa;
+ struct acpi_dmar_satc *satc;
switch (header->type) {
case ACPI_DMAR_TYPE_HARDWARE_UNIT:
@@ -555,6 +556,10 @@ dmar_table_print_dmar_entry(struct acpi_dmar_header
*header)
/* We don't print this here because we need to sanity-check
it first. So print it in dmar_parse_one_andd() instead. */
break;
+ case ACPI_DMAR_TYPE_SATC:
+ satc = container_of(header, struct acpi_dmar_satc, header);
+ pr_info("SATC flags: 0x%x\n", satc->flags);
+ break;
}
}
@@ -642,6 +647,7 @@ parse_dmar_table(void)
.cb[ACPI_DMAR_TYPE_ROOT_ATS] = &dmar_parse_one_atsr,
.cb[ACPI_DMAR_TYPE_HARDWARE_AFFINITY] = &dmar_parse_one_rhsa,
.cb[ACPI_DMAR_TYPE_NAMESPACE] = &dmar_parse_one_andd,
+ .cb[ACPI_DMAR_TYPE_SATC] = &dmar_parse_one_satc,
};
/*
@@ -2077,6 +2083,7 @@ static guid_t dmar_hp_guid =
#defineDMAR_DSM_FUNC_DRHD 1
#defineDMAR_DSM_FUNC_ATSR 2
#defineDMAR_DSM_FUNC_RHSA 3
+#defineDMAR_DSM_FUNC_SATC 4
static inline bool dmar_detect_dsm(acpi_handle handle, int func)
{
@@ -2094,6 +2101,7 @@ static int dmar_walk_dsm_resource(acpi_handle handle, int
func,
[DMAR_DSM_FUNC_DRHD] = ACPI_DMAR_TYPE_HARDWARE_UNIT,
[DMAR_DSM_FUNC_ATSR] = ACPI_DMAR_TYPE_ROOT_ATS,
[DMAR_DSM_FUNC_RHSA] = ACPI_DMAR_TYPE_HARDWARE_AFFINITY,
+ [DMAR_DSM_FUNC_SATC] = ACPI_DMAR_TYPE_SATC,
};
if (!dmar_detect_dsm(handle, func))
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ecbd05d8a1fc..ee0932307d64 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -316,8 +316,18 @@ struct dmar_atsr_unit {
u8 include_all:1; /* include all ports */
};
+struct dmar_satc_unit {
+ struct list_head list; /* list of SATC units */
+ struct acpi_dmar_header *hdr; /* ACPI header */
+ struct dmar_dev_scope *devices; /* target devices */
+ struct intel_iommu *iommu; /* the corresponding iommu */
+ int devices_cnt;/* target device count */
+ u8 atc_required:1; /* ATS is required */
+};
+
static LIST_HEAD(dmar_atsr_units);
static LIST_HEAD(dmar_rmrr_units);
+static LIST_HEAD(dmar_satc_units);
#define for_each_rmrr_units(rmrr) \
list_for_each_entry(rmrr, &dmar_rmrr_units, list)
@@ -3716,6 +3726,57 @@ int dmar_check_one_atsr(struct acpi_dmar_header *hdr,
void *arg)
return 0;
}
+static struct dmar_satc_unit *dmar_find_satc(struct acpi_dmar_satc *satc)
+{
+ struct dmar_satc_unit *satcu;
+ struct acpi_dmar_satc *tmp;
+
+ list_for_each_entry_rcu(satcu, &dmar_satc_units, list,
+ dmar_rcu_check()) {
+ tmp = (struct acpi_dmar_satc *)satcu->hdr;
+ if (satc->segment != tmp->segment)
+ continue;
+ if (satc->header.length != tmp->header.length)
+ continue;
+ if (memcmp(satc, tmp, satc->header.length) == 0)
+ return satcu;
+ }
+
+ return NULL;
+}
+
+int dmar_parse_one_satc(struct acpi_dmar_header *hdr, void *arg)
+{
+ struct acpi_dmar_satc *satc;
+ struct dmar_satc_unit *satcu;
+
+ if (system_state >= SYSTEM_RUNNING && !intel_iommu_enabled)
+ return 0;
+
+ satc = container_of(hdr, struct acpi_dmar_satc, header);
+ satcu = dmar_find_satc(satc);
+ if (satcu)
+ return 0;
+
+ satcu = kzalloc(sizeof(*satcu) + hdr->length, GFP_KERNEL);
+ if (!satcu)
+ return -ENOMEM;
+
+ satcu->hdr = (void *)(satcu + 1);
+ memcpy(satcu->hdr, hdr, hdr->length);
+ satcu->atc_required = satc->flags & 0x1;
+ satcu->devices = dmar_alloc_dev_scope((void *)(satc + 1),
+ (void *)satc +
satc->header
[PATCH 5/7] iommu/vt-d: Add new enum value and structure for SATC
From: Yian Chen
Starting from Intel Platform VT-d v3.2, BIOS may provide new remapping
structure SATC for SOC integrated devices, according to section 8.8 of
Intel VT-d architecture specification v3.2. The SATC structure reports
a list of the devices that require ATS for normal device operation. It
is a functional requirement that these devices will not work without OS
enabling ATS capability.
This patch introduces the new enum value and structure to represent the
remapping information. Kernel should parse the information from the
reporting structure and enable ATC for the devices as needed.
Signed-off-by: Yian Chen
Link:
https://lore.kernel.org/r/20210203093329.1617808-1-baolu...@linux.intel.com
Signed-off-by: Lu Baolu
---
include/acpi/actbl1.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 43549547ed3e..c38e08cf1b9e 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -514,7 +514,8 @@ enum acpi_dmar_type {
ACPI_DMAR_TYPE_ROOT_ATS = 2,
ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,
ACPI_DMAR_TYPE_NAMESPACE = 4,
- ACPI_DMAR_TYPE_RESERVED = 5 /* 5 and greater are reserved */
+ ACPI_DMAR_TYPE_SATC = 5,
+ ACPI_DMAR_TYPE_RESERVED = 6 /* 6 and greater are reserved */
};
/* DMAR Device Scope structure */
@@ -607,6 +608,14 @@ struct acpi_dmar_andd {
char device_name[1];
};
+/* 5: SOC Integrated Address Translation Cache Reporting Structure */
+
+struct acpi_dmar_satc {
+ struct acpi_dmar_header header;
+ u8 flags;
+ u8 reserved;
+ u16 segment;
+};
/***
*
* DRTM - Dynamic Root of Trust for Measurement table
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 4/7] iommu/vt-d: Add iotlb_sync_map callback
Some Intel VT-d hardware implementations don't support memory coherency
for page table walk (presented by the Page-Walk-coherency bit in the
ecap register), so that software must flush the corresponding CPU cache
lines explicitly after each page table entry update.
The iommu_map_sg() code iterates through the given scatter-gather list
and invokes iommu_map() for each element in the scatter-gather list,
which calls into the vendor IOMMU driver through iommu_ops callback. As
the result, a single sg mapping may lead to multiple cache line flushes,
which leads to the degradation of I/O performance after the commit
("iommu/vt-d: Convert intel iommu driver to the iommu
ops").
Fix this by adding iotlb_sync_map callback and centralizing the clflush
operations after all sg mappings.
Fixes: c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
Reported-by: Chuck Lever
Link:
https://lore.kernel.org/linux-iommu/d81314ed-5673-44a6-b597-090e3cb83...@oracle.com/
Signed-off-by: Lu Baolu
Cc: Robin Murphy
[ cel: removed @first_pte, which is no longer used ]
Signed-off-by: Chuck Lever
Link:
https://lore.kernel.org/linux-iommu/161177763962.1311.15577661784296014186.st...@manet.1015granger.net
---
drivers/iommu/intel/iommu.c | 90 -
1 file changed, 60 insertions(+), 30 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ecd36e456de3..ecbd05d8a1fc 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2283,9 +2283,9 @@ static int
__domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
unsigned long phys_pfn, unsigned long nr_pages, int prot)
{
- struct dma_pte *first_pte = NULL, *pte = NULL;
unsigned int largepage_lvl = 0;
unsigned long lvl_pages = 0;
+ struct dma_pte *pte = NULL;
phys_addr_t pteval;
u64 attr;
@@ -2314,7 +2314,7 @@ __domain_mapping(struct dmar_domain *domain, unsigned
long iov_pfn,
largepage_lvl = hardware_largepage_caps(domain, iov_pfn,
phys_pfn, nr_pages);
- first_pte = pte = pfn_to_dma_pte(domain, iov_pfn,
&largepage_lvl);
+ pte = pfn_to_dma_pte(domain, iov_pfn, &largepage_lvl);
if (!pte)
return -ENOMEM;
/* It is large page*/
@@ -2375,34 +2375,14 @@ __domain_mapping(struct dmar_domain *domain, unsigned
long iov_pfn,
* recalculate 'pte' and switch back to smaller pages for the
* end of the mapping, if the trailing size is not enough to
* use another superpage (i.e. nr_pages < lvl_pages).
+*
+* We leave clflush for the leaf pte changes to iotlb_sync_map()
+* callback.
*/
pte++;
if (!nr_pages || first_pte_in_page(pte) ||
- (largepage_lvl > 1 && nr_pages < lvl_pages)) {
- domain_flush_cache(domain, first_pte,
- (void *)pte - (void *)first_pte);
+ (largepage_lvl > 1 && nr_pages < lvl_pages))
pte = NULL;
- }
- }
-
- return 0;
-}
-
-static int
-domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,
- unsigned long phys_pfn, unsigned long nr_pages, int prot)
-{
- int iommu_id, ret;
- struct intel_iommu *iommu;
-
- /* Do the real mapping first */
- ret = __domain_mapping(domain, iov_pfn, phys_pfn, nr_pages, prot);
- if (ret)
- return ret;
-
- for_each_domain_iommu(iommu_id, domain) {
- iommu = g_iommus[iommu_id];
- __mapping_notify_one(iommu, domain, iov_pfn, nr_pages);
}
return 0;
@@ -4943,7 +4923,6 @@ static int intel_iommu_map(struct iommu_domain *domain,
struct dmar_domain *dmar_domain = to_dmar_domain(domain);
u64 max_addr;
int prot = 0;
- int ret;
if (iommu_prot & IOMMU_READ)
prot |= DMA_PTE_READ;
@@ -4969,9 +4948,8 @@ static int intel_iommu_map(struct iommu_domain *domain,
/* Round up size to next multiple of PAGE_SIZE, if it and
the low bits of hpa would take us onto the next page */
size = aligned_nrpages(hpa, size);
- ret = domain_mapping(dmar_domain, iova >> VTD_PAGE_SHIFT,
-hpa >> VTD_PAGE_SHIFT, size, prot);
- return ret;
+ return __domain_mapping(dmar_domain, iova >> VTD_PAGE_SHIFT,
+ hpa >> VTD_PAGE_SHIFT, size, prot);
}
static size_t intel_iommu_unmap(struct iommu_domain *domain,
@@ -5454,6 +5432,57 @@ static bool risky_device(struct pci_dev *pdev)
return false;
}
+static void clflush_sync_map(struct dmar_domain *domain, unsigned
[PATCH 2/7] iommu/vt-d: Audit IOMMU Capabilities and add helper functions
From: Kyung Min Park
Audit IOMMU Capability/Extended Capability and check if the IOMMUs have
the consistent value for features. Report out or scale to the lowest
supported when IOMMU features have incompatibility among IOMMUs.
Report out features when below features are mismatched:
- First Level 5 Level Paging Support (FL5LP)
- First Level 1 GByte Page Support (FL1GP)
- Read Draining (DRD)
- Write Draining (DWD)
- Page Selective Invalidation (PSI)
- Zero Length Read (ZLR)
- Caching Mode (CM)
- Protected High/Low-Memory Region (PHMR/PLMR)
- Required Write-Buffer Flushing (RWBF)
- Advanced Fault Logging (AFL)
- RID-PASID Support (RPS)
- Scalable Mode Page Walk Coherency (SMPWC)
- First Level Translation Support (FLTS)
- Second Level Translation Support (SLTS)
- No Write Flag Support (NWFS)
- Second Level Accessed/Dirty Support (SLADS)
- Virtual Command Support (VCS)
- Scalable Mode Translation Support (SMTS)
- Device TLB Invalidation Throttle (DIT)
- Page Drain Support (PDS)
- Process Address Space ID Support (PASID)
- Extended Accessed Flag Support (EAFS)
- Supervisor Request Support (SRS)
- Execute Request Support (ERS)
- Page Request Support (PRS)
- Nested Translation Support (NEST)
- Snoop Control (SC)
- Pass Through (PT)
- Device TLB Support (DT)
- Queued Invalidation (QI)
- Page walk Coherency (C)
Set capability to the lowest supported when below features are mismatched:
- Maximum Address Mask Value (MAMV)
- Number of Fault Recording Registers (NFR)
- Second Level Large Page Support (SLLPS)
- Fault Recording Offset (FRO)
- Maximum Guest Address Width (MGAW)
- Supported Adjusted Guest Address Width (SAGAW)
- Number of Domains supported (NDOMS)
- Pasid Size Supported (PSS)
- Maximum Handle Mask Value (MHMV)
- IOTLB Register Offset (IRO)
Signed-off-by: Kyung Min Park
Link: https://lore.kernel.org/r/20210130184452.31711-1-kyung.min.p...@intel.com
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/Makefile| 2 +-
drivers/iommu/intel/cap_audit.c | 185
drivers/iommu/intel/cap_audit.h | 110 +
drivers/iommu/intel/iommu.c | 9 ++
drivers/iommu/intel/irq_remapping.c | 8 ++
include/linux/intel-iommu.h | 39 +++---
6 files changed, 334 insertions(+), 19 deletions(-)
create mode 100644 drivers/iommu/intel/cap_audit.c
create mode 100644 drivers/iommu/intel/cap_audit.h
diff --git a/drivers/iommu/intel/Makefile b/drivers/iommu/intel/Makefile
index ae570810a35e..ae236ec7d219 100644
--- a/drivers/iommu/intel/Makefile
+++ b/drivers/iommu/intel/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += iommu.o pasid.o
-obj-$(CONFIG_DMAR_TABLE) += trace.o
+obj-$(CONFIG_DMAR_TABLE) += trace.o cap_audit.o
obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += debugfs.o
obj-$(CONFIG_INTEL_IOMMU_SVM) += svm.o
obj-$(CONFIG_IRQ_REMAP) += irq_remapping.o
diff --git a/drivers/iommu/intel/cap_audit.c b/drivers/iommu/intel/cap_audit.c
new file mode 100644
index ..049bc0c76a00
--- /dev/null
+++ b/drivers/iommu/intel/cap_audit.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * cap_audit.c - audit iommu capabilities for boot time and hot plug
+ *
+ * Copyright (C) 2021 Intel Corporation
+ *
+ * Author: Kyung Min Park
+ * Lu Baolu
+ */
+
+#define pr_fmt(fmt)"DMAR: " fmt
+
+#include
+#include "cap_audit.h"
+
+static u64 intel_iommu_cap_sanity;
+static u64 intel_iommu_ecap_sanity;
+
+static inline void check_irq_capabilities(struct intel_iommu *a,
+ struct intel_iommu *b)
+{
+ CHECK_FEATURE_MISMATCH(a, b, cap, pi_support, CAP_PI_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, ecap, eim_support, ECAP_EIM_MASK);
+}
+
+static inline void check_dmar_capabilities(struct intel_iommu *a,
+ struct intel_iommu *b)
+{
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_MAMV_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_NFR_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_SLLPS_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_FRO_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_MGAW_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_SAGAW_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_NDOMS_MASK);
+ MINIMAL_FEATURE_IOMMU(b, ecap, ECAP_PSS_MASK);
+ MINIMAL_FEATURE_IOMMU(b, ecap, ECAP_MHMV_MASK);
+ MINIMAL_FEATURE_IOMMU(b, ecap, ECAP_IRO_MASK);
+
+ CHECK_FEATURE_MISMATCH(a, b, cap, 5lp_support, CAP_FL5LP_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, fl1gp_support, CAP_FL1GP_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, read_drain, CAP_RD_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, write_drain, CAP_WD_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, pgsel_inv, CAP_PSI_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, zlr, CAP_ZLR_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, c
[PATCH 3/7] iommu/vt-d: Move capability check code to cap_audit files
From: Kyung Min Park
Move IOMMU capability check and sanity check code to cap_audit files.
Also implement some helper functions for sanity checks.
Signed-off-by: Kyung Min Park
Link: https://lore.kernel.org/r/20210130184452.31711-1-kyung.min.p...@intel.com
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/cap_audit.c | 20 +
drivers/iommu/intel/cap_audit.h | 20 +
drivers/iommu/intel/iommu.c | 76 +
3 files changed, 42 insertions(+), 74 deletions(-)
diff --git a/drivers/iommu/intel/cap_audit.c b/drivers/iommu/intel/cap_audit.c
index 049bc0c76a00..b12e421a2f1a 100644
--- a/drivers/iommu/intel/cap_audit.c
+++ b/drivers/iommu/intel/cap_audit.c
@@ -183,3 +183,23 @@ int intel_cap_audit(enum cap_audit_type type, struct
intel_iommu *iommu)
return -EFAULT;
}
+
+bool intel_cap_smts_sanity(void)
+{
+ return ecap_smts(intel_iommu_ecap_sanity);
+}
+
+bool intel_cap_pasid_sanity(void)
+{
+ return ecap_pasid(intel_iommu_ecap_sanity);
+}
+
+bool intel_cap_nest_sanity(void)
+{
+ return ecap_nest(intel_iommu_ecap_sanity);
+}
+
+bool intel_cap_flts_sanity(void)
+{
+ return ecap_flts(intel_iommu_ecap_sanity);
+}
diff --git a/drivers/iommu/intel/cap_audit.h b/drivers/iommu/intel/cap_audit.h
index a6a1530441b7..74cfccae0e81 100644
--- a/drivers/iommu/intel/cap_audit.h
+++ b/drivers/iommu/intel/cap_audit.h
@@ -107,4 +107,24 @@ enum cap_audit_type {
CAP_AUDIT_HOTPLUG_IRQR,
};
+bool intel_cap_smts_sanity(void);
+bool intel_cap_pasid_sanity(void);
+bool intel_cap_nest_sanity(void);
+bool intel_cap_flts_sanity(void);
+
+static inline bool scalable_mode_support(void)
+{
+ return (intel_iommu_sm && intel_cap_smts_sanity());
+}
+
+static inline bool pasid_mode_support(void)
+{
+ return scalable_mode_support() && intel_cap_pasid_sanity();
+}
+
+static inline bool nested_mode_support(void)
+{
+ return scalable_mode_support() && intel_cap_nest_sanity();
+}
+
int intel_cap_audit(enum cap_audit_type type, struct intel_iommu *iommu);
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index b948f43c6a97..ecd36e456de3 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -1864,25 +1864,7 @@ static void free_dmar_iommu(struct intel_iommu *iommu)
*/
static bool first_level_by_default(void)
{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- static int first_level_support = -1;
-
- if (likely(first_level_support != -1))
- return first_level_support;
-
- first_level_support = 1;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!sm_supported(iommu) || !ecap_flts(iommu->ecap)) {
- first_level_support = 0;
- break;
- }
- }
- rcu_read_unlock();
-
- return first_level_support;
+ return scalable_mode_support() && intel_cap_flts_sanity();
}
static struct dmar_domain *alloc_domain(int flags)
@@ -5058,60 +5040,6 @@ static phys_addr_t intel_iommu_iova_to_phys(struct
iommu_domain *domain,
return phys;
}
-static inline bool scalable_mode_support(void)
-{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- bool ret = true;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!sm_supported(iommu)) {
- ret = false;
- break;
- }
- }
- rcu_read_unlock();
-
- return ret;
-}
-
-static inline bool iommu_pasid_support(void)
-{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- bool ret = true;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!pasid_supported(iommu)) {
- ret = false;
- break;
- }
- }
- rcu_read_unlock();
-
- return ret;
-}
-
-static inline bool nested_mode_support(void)
-{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- bool ret = true;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!sm_supported(iommu) || !ecap_nest(iommu->ecap)) {
- ret = false;
- break;
- }
- }
- rcu_read_unlock();
-
- return ret;
-}
-
static bool intel_iommu_capable(enum iommu_cap cap)
{
if (cap == IOMMU_CAP_CACHE_COHERENCY)
@@ -5352,7 +5280,7 @@ intel_iommu_dev_has_feat(struct device *dev, enum
iommu_dev_features feat)
int ret;
if (!dev_is_pci(dev) || dmar_disabled ||
- !scalable_mode_support() || !iommu_pasid_support())
+ !scalable_mode_support() || !pasid_mode_support())
return false;
ret = pci_pasid_features(to_pci_dev(dev));
--
2.25.1
__
[PATCH 1/7] iommu/vt-d: Fix 'physical' typos
From: Bjorn Helgaas
Fix misspellings of "physical".
Signed-off-by: Bjorn Helgaas
Link:
https://lore.kernel.org/linux-iommu/20210126211738.2920789-1-helg...@kernel.org
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index ecb35fdff03e..f8ab154c979d 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -664,7 +664,7 @@ static inline struct dmar_domain *to_dmar_domain(struct
iommu_domain *dom)
* 7: super page
* 8-10: available
* 11: snoop behavior
- * 12-63: Host physcial address
+ * 12-63: Host physical address
*/
struct dma_pte {
u64 val;
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/7] [PULL REQUEST] iommu/vt-d: Update for v5.12
Hi Joerg, The patches queued in this series is for v5.12. It includes: - Audit capability consistency among different IOMMUs - Add SATC reporting structure support - Add iotlb_sync_map callback support - Misc cleanup Please consider them for v5.12. Best regards, Lu Baolu Bjorn Helgaas (1): iommu/vt-d: Fix 'physical' typos Kyung Min Park (2): iommu/vt-d: Audit IOMMU Capabilities and add helper functions iommu/vt-d: Move capability check code to cap_audit files Lu Baolu (1): iommu/vt-d: Add iotlb_sync_map callback Yian Chen (3): iommu/vt-d: Add new enum value and structure for SATC iommu/vt-d: Parse SATC reporting structure iommu/vt-d: Apply SATC policy drivers/iommu/intel/Makefile| 2 +- drivers/iommu/intel/cap_audit.c | 205 + drivers/iommu/intel/cap_audit.h | 130 +++ drivers/iommu/intel/dmar.c | 8 + drivers/iommu/intel/iommu.c | 337 +++- drivers/iommu/intel/irq_remapping.c | 8 + include/acpi/actbl1.h | 11 +- include/linux/dmar.h| 2 + include/linux/intel-iommu.h | 41 ++-- 9 files changed, 615 insertions(+), 129 deletions(-) create mode 100644 drivers/iommu/intel/cap_audit.c create mode 100644 drivers/iommu/intel/cap_audit.h -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/3] dt-bindings: iommu: renesas,ipmmu-vmsa: Make 'power-domains' conditionally required
Hi Rob, > From: Rob Herring, Sent: Wednesday, February 3, 2021 5:56 AM > > Fixing the compatible string typos results in an error in the example: > > Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.example.dt.yaml: > iommu@fe951000: 'power-domains' is a required property > > Based on the dts files, a 'power-domains' property only exists on Gen 3 > which can be conditioned on !renesas,ipmmu-vmsa. > > Cc: Joerg Roedel > Cc: Will Deacon > Cc: Yoshihiro Shimoda > Cc: iommu@lists.linux-foundation.org > Signed-off-by: Rob Herring Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
Hi Rob,
> From: Rob Herring, Sent: Wednesday, February 3, 2021 5:56 AM
>
> Running 'dt-validate -m' will flag any compatible strings missing a schema.
> Fix all the errors found in DT binding examples. Most of these are just
> typos.
>
> Cc: Stephen Boyd
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Linus Walleij
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Daniel Palmer
> Cc: Bartosz Golaszewski
> Cc: Avi Fishman
> Cc: Tomer Maimon
> Cc: Tali Perry
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Andrew Jeffery
> Cc: Joel Stanley
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Cc: Yoshihiro Shimoda
> Cc: Vincent Cheng
> Cc: linux-...@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Rob Herring
> diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> index cde1afa8dfd6..349633108bbd 100644
> --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
> @@ -93,7 +93,7 @@ examples:
> #include
>
> ipmmu_mx: iommu@fe951000 {
> -compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
> +compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
Oops. Thank you for fixing this.
Reviewed-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH][next] iommu/mediatek: Fix unsigned domid comparison with less than zero
On Wed, 2021-02-03 at 13:59 +, Colin King wrote:
> From: Colin Ian King
>
> Currently the check for domid < 0 is always false because domid
> is unsigned. Fix this by making it signed.
>
> Addresses-CoverityL ("Unsigned comparison against 0")
> Fixes: ab1d5281a62b ("iommu/mediatek: Add iova reserved function")
> Signed-off-by: Colin Ian King
Thanks for the fix.
Reviewed-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 0ad14a7604b1..823d719945b2 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -640,7 +640,7 @@ static void mtk_iommu_get_resv_regions(struct device *dev,
> struct list_head *head)
> {
> struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
> - unsigned int domid = mtk_iommu_get_domain_id(dev, data->plat_data), i;
> + int domid = mtk_iommu_get_domain_id(dev, data->plat_data), i;
> const struct mtk_iommu_iova_region *resv, *curdom;
> struct iommu_resv_region *region;
> int prot = IOMMU_WRITE | IOMMU_READ;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH RFC v1 6/6] xen-swiotlb: enable 64-bit xen-swiotlb
This patch is to enable the 64-bit xen-swiotlb buffer.
For Xen PVM DMA address, the 64-bit device will be able to allocate from
64-bit swiotlb buffer.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
drivers/xen/swiotlb-xen.c | 117 --
1 file changed, 74 insertions(+), 43 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index e18cae693cdc..c9ab07809e32 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -108,27 +108,36 @@ static int is_xen_swiotlb_buffer(struct device *dev,
dma_addr_t dma_addr)
unsigned long bfn = XEN_PFN_DOWN(dma_to_phys(dev, dma_addr));
unsigned long xen_pfn = bfn_to_local_pfn(bfn);
phys_addr_t paddr = (phys_addr_t)xen_pfn << XEN_PAGE_SHIFT;
+ int i;
/* If the address is outside our domain, it CAN
* have the same virtual address as another address
* in our domain. Therefore _only_ check address within our domain.
*/
- if (pfn_valid(PFN_DOWN(paddr))) {
- return paddr >= virt_to_phys(xen_io_tlb_start[SWIOTLB_LO]) &&
- paddr < virt_to_phys(xen_io_tlb_end[SWIOTLB_LO]);
- }
+ if (!pfn_valid(PFN_DOWN(paddr)))
+ return 0;
+
+ for (i = 0; i < swiotlb_nr; i++)
+ if (paddr >= virt_to_phys(xen_io_tlb_start[i]) &&
+ paddr < virt_to_phys(xen_io_tlb_end[i]))
+ return 1;
+
return 0;
}
static int
-xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
+xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs,
+ enum swiotlb_t type)
{
int i, rc;
int dma_bits;
dma_addr_t dma_handle;
phys_addr_t p = virt_to_phys(buf);
- dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
+ if (type == SWIOTLB_HI)
+ dma_bits = max_dma_bits[SWIOTLB_HI];
+ else
+ dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) +
PAGE_SHIFT;
i = 0;
do {
@@ -139,7 +148,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
p + (i << IO_TLB_SHIFT),
get_order(slabs << IO_TLB_SHIFT),
dma_bits, &dma_handle);
- } while (rc && dma_bits++ < max_dma_bits[SWIOTLB_LO]);
+ } while (rc && dma_bits++ < max_dma_bits[type]);
if (rc)
return rc;
@@ -147,16 +156,17 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
} while (i < nslabs);
return 0;
}
-static unsigned long xen_set_nslabs(unsigned long nr_tbl)
+
+static unsigned long xen_set_nslabs(unsigned long nr_tbl, enum swiotlb_t type)
{
if (!nr_tbl) {
- xen_io_tlb_nslabs[SWIOTLB_LO] = (64 * 1024 * 1024 >>
IO_TLB_SHIFT);
- xen_io_tlb_nslabs[SWIOTLB_LO] =
ALIGN(xen_io_tlb_nslabs[SWIOTLB_LO],
+ xen_io_tlb_nslabs[type] = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
+ xen_io_tlb_nslabs[type] = ALIGN(xen_io_tlb_nslabs[type],
IO_TLB_SEGSIZE);
} else
- xen_io_tlb_nslabs[SWIOTLB_LO] = nr_tbl;
+ xen_io_tlb_nslabs[type] = nr_tbl;
- return xen_io_tlb_nslabs[SWIOTLB_LO] << IO_TLB_SHIFT;
+ return xen_io_tlb_nslabs[type] << IO_TLB_SHIFT;
}
enum xen_swiotlb_err {
@@ -180,23 +190,24 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err
err)
}
return "";
}
-int __ref xen_swiotlb_init(int verbose, bool early)
+
+static int xen_swiotlb_init_type(int verbose, bool early, enum swiotlb_t type)
{
unsigned long bytes, order;
int rc = -ENOMEM;
enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
unsigned int repeat = 3;
- xen_io_tlb_nslabs[SWIOTLB_LO] = swiotlb_nr_tbl(SWIOTLB_LO);
+ xen_io_tlb_nslabs[type] = swiotlb_nr_tbl(type);
retry:
- bytes = xen_set_nslabs(xen_io_tlb_nslabs[SWIOTLB_LO]);
- order = get_order(xen_io_tlb_nslabs[SWIOTLB_LO] << IO_TLB_SHIFT);
+ bytes = xen_set_nslabs(xen_io_tlb_nslabs[type], type);
+ order = get_order(xen_io_tlb_nslabs[type] << IO_TLB_SHIFT);
/*
* IO TLB memory already allocated. Just use it.
*/
- if (io_tlb_start[SWIOTLB_LO] != 0) {
- xen_io_tlb_start[SWIOTLB_LO] =
phys_to_virt(io_tlb_start[SWIOTLB_LO]);
+ if (io_tlb_start[type] != 0) {
+ xen_io_tlb_start[type] = phys_to_virt(io_tlb_start[type]);
goto end;
}
@@ -204,81 +215,95 @@ int __ref xen_swiotlb_init(int verbose, bool early)
* Get IO TLB memory from any location.
*/
if (early) {
- xen_io_tlb_start[SWIOTLB_LO] = memblock_alloc(PAGE_ALIGN(bytes),
+ xen_io_tlb_start[type] = memblock_alloc(PAGE_ALI
[PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays
This patch converts several xen-swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- xen_io_tlb_start and xen_io_tlb_end
- xen_io_tlb_nslabs
- MAX_DMA_BITS
There is no functional change and this is to prepare to enable 64-bit
xen-swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
drivers/xen/swiotlb-xen.c | 75 +--
1 file changed, 40 insertions(+), 35 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 662638093542..e18cae693cdc 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -39,15 +39,17 @@
#include
#include
-#define MAX_DMA_BITS 32
/*
* Used to do a quick range check in swiotlb_tbl_unmap_single and
* swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
* API.
*/
-static char *xen_io_tlb_start, *xen_io_tlb_end;
-static unsigned long xen_io_tlb_nslabs;
+static char *xen_io_tlb_start[SWIOTLB_MAX], *xen_io_tlb_end[SWIOTLB_MAX];
+static unsigned long xen_io_tlb_nslabs[SWIOTLB_MAX];
+
+static int max_dma_bits[] = {32, 64};
+
/*
* Quick lookup value of the bus address of the IOTLB.
*/
@@ -112,8 +114,8 @@ static int is_xen_swiotlb_buffer(struct device *dev,
dma_addr_t dma_addr)
* in our domain. Therefore _only_ check address within our domain.
*/
if (pfn_valid(PFN_DOWN(paddr))) {
- return paddr >= virt_to_phys(xen_io_tlb_start) &&
- paddr < virt_to_phys(xen_io_tlb_end);
+ return paddr >= virt_to_phys(xen_io_tlb_start[SWIOTLB_LO]) &&
+ paddr < virt_to_phys(xen_io_tlb_end[SWIOTLB_LO]);
}
return 0;
}
@@ -137,7 +139,7 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
p + (i << IO_TLB_SHIFT),
get_order(slabs << IO_TLB_SHIFT),
dma_bits, &dma_handle);
- } while (rc && dma_bits++ < MAX_DMA_BITS);
+ } while (rc && dma_bits++ < max_dma_bits[SWIOTLB_LO]);
if (rc)
return rc;
@@ -148,12 +150,13 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
static unsigned long xen_set_nslabs(unsigned long nr_tbl)
{
if (!nr_tbl) {
- xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
- xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
+ xen_io_tlb_nslabs[SWIOTLB_LO] = (64 * 1024 * 1024 >>
IO_TLB_SHIFT);
+ xen_io_tlb_nslabs[SWIOTLB_LO] =
ALIGN(xen_io_tlb_nslabs[SWIOTLB_LO],
+ IO_TLB_SEGSIZE);
} else
- xen_io_tlb_nslabs = nr_tbl;
+ xen_io_tlb_nslabs[SWIOTLB_LO] = nr_tbl;
- return xen_io_tlb_nslabs << IO_TLB_SHIFT;
+ return xen_io_tlb_nslabs[SWIOTLB_LO] << IO_TLB_SHIFT;
}
enum xen_swiotlb_err {
@@ -184,16 +187,16 @@ int __ref xen_swiotlb_init(int verbose, bool early)
enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
unsigned int repeat = 3;
- xen_io_tlb_nslabs = swiotlb_nr_tbl(SWIOTLB_LO);
+ xen_io_tlb_nslabs[SWIOTLB_LO] = swiotlb_nr_tbl(SWIOTLB_LO);
retry:
- bytes = xen_set_nslabs(xen_io_tlb_nslabs);
- order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
+ bytes = xen_set_nslabs(xen_io_tlb_nslabs[SWIOTLB_LO]);
+ order = get_order(xen_io_tlb_nslabs[SWIOTLB_LO] << IO_TLB_SHIFT);
/*
* IO TLB memory already allocated. Just use it.
*/
if (io_tlb_start[SWIOTLB_LO] != 0) {
- xen_io_tlb_start = phys_to_virt(io_tlb_start[SWIOTLB_LO]);
+ xen_io_tlb_start[SWIOTLB_LO] =
phys_to_virt(io_tlb_start[SWIOTLB_LO]);
goto end;
}
@@ -201,76 +204,78 @@ int __ref xen_swiotlb_init(int verbose, bool early)
* Get IO TLB memory from any location.
*/
if (early) {
- xen_io_tlb_start = memblock_alloc(PAGE_ALIGN(bytes),
+ xen_io_tlb_start[SWIOTLB_LO] = memblock_alloc(PAGE_ALIGN(bytes),
PAGE_SIZE);
- if (!xen_io_tlb_start)
+ if (!xen_io_tlb_start[SWIOTLB_LO])
panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
__func__, PAGE_ALIGN(bytes), PAGE_SIZE);
} else {
#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
- xen_io_tlb_start = (void
*)xen_get_swiotlb_free_pages(order);
- if (xen_io_tlb_start)
+ xen_io_tlb_start[SWIOTLB_LO] = (void
*)xen_get_swiotlb_free_pages(order);
+ if (xen_io_tlb_start
[PATCH RFC v1 4/6] swiotlb: enable 64-bit swiotlb
This patch is to enable the 64-bit swiotlb buffer.
The state of the art swiotlb pre-allocates <=32-bit memory in order to meet
the DMA mask requirement for some 32-bit legacy device. Considering most
devices nowadays support 64-bit DMA and IOMMU is available, the swiotlb is
not used for most of the times, except:
1. The xen PVM domain requires the DMA addresses to both (1) less than the
dma mask, and (2) continuous in machine address. Therefore, the 64-bit
device may still require swiotlb on PVM domain.
2. From source code the AMD SME/SEV will enable SWIOTLB_FORCE. As a result
it is always required to allocate from swiotlb buffer even the device dma
mask is 64-bit.
sme_early_init()
-> if (sev_active())
swiotlb_force = SWIOTLB_FORCE;
Therefore, this patch introduces the 2nd swiotlb buffer for 64-bit DMA
access. For instance, the swiotlb_tbl_map_single() allocates from the 2nd
64-bit buffer if the device DMA mask is
min_not_zero(*hwdev->dma_mask, hwdev->bus_dma_limit).
The example to configure 64-bit swiotlb is "swiotlb=65536,524288,force"
or "swiotlb=,524288,force", where 524288 is the size of 64-bit buffer.
With the patch, the kernel will be able to allocate >4GB swiotlb buffer.
This patch is only for swiotlb, not including xen-swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
arch/mips/cavium-octeon/dma-octeon.c | 3 +-
arch/powerpc/kernel/dma-swiotlb.c| 2 +-
arch/powerpc/platforms/pseries/svm.c | 2 +-
arch/x86/kernel/pci-swiotlb.c| 5 +-
arch/x86/pci/sta2x11-fixup.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +-
drivers/gpu/drm/i915/i915_scatterlist.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/mmc/host/sdhci.c | 2 +-
drivers/pci/xen-pcifront.c | 2 +-
drivers/xen/swiotlb-xen.c| 9 +-
include/linux/swiotlb.h | 28 +-
kernel/dma/swiotlb.c | 339 +++
13 files changed, 238 insertions(+), 164 deletions(-)
diff --git a/arch/mips/cavium-octeon/dma-octeon.c
b/arch/mips/cavium-octeon/dma-octeon.c
index df70308db0e6..3480555d908a 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -245,6 +245,7 @@ void __init plat_swiotlb_setup(void)
panic("%s: Failed to allocate %zu bytes align=%lx\n",
__func__, swiotlbsize, PAGE_SIZE);
- if (swiotlb_init_with_tbl(octeon_swiotlb, swiotlb_nslabs, 1) == -ENOMEM)
+ if (swiotlb_init_with_tbl(octeon_swiotlb, swiotlb_nslabs,
+ SWIOTLB_LO, 1) == -ENOMEM)
panic("Cannot allocate SWIOTLB buffer");
}
diff --git a/arch/powerpc/kernel/dma-swiotlb.c
b/arch/powerpc/kernel/dma-swiotlb.c
index fc7816126a40..88113318c53f 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -20,7 +20,7 @@ void __init swiotlb_detect_4g(void)
static int __init check_swiotlb_enabled(void)
{
if (ppc_swiotlb_enable)
- swiotlb_print_info();
+ swiotlb_print_info(SWIOTLB_LO);
else
swiotlb_exit();
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
index 9f8842d0da1f..77910e4ffad8 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -52,7 +52,7 @@ void __init svm_swiotlb_init(void)
bytes = io_tlb_nslabs << IO_TLB_SHIFT;
vstart = memblock_alloc(PAGE_ALIGN(bytes), PAGE_SIZE);
- if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, false))
+ if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, SWIOTLB_LO,
false))
return;
if (io_tlb_start[SWIOTLB_LO])
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index c2cfa5e7c152..950624fd95a4 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -67,12 +67,15 @@ void __init pci_swiotlb_init(void)
void __init pci_swiotlb_late_init(void)
{
+ int i;
+
/* An IOMMU turned us off. */
if (!swiotlb)
swiotlb_exit();
else {
printk(KERN_INFO "PCI-DMA: "
"Using software bounce buffering for IO (SWIOTLB)\n");
- swiotlb_print_info();
+ for (i = 0; i < swiotlb_nr; i++)
+ swiotlb_print_info(i);
}
}
diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 7d2525691854..c440520b2055 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -57,7 +57,7 @@ static void sta2x11_new_instance(struct pci_dev *pdev)
int size = STA2X11_SWIOTLB_SIZE;
/* First instance: register your own swiotlb area */
dev_info(&pdev->dev, "Using SWIOTLB (size %i)\n", size);
-
[PATCH RFC v1 0/6] swiotlb: 64-bit DMA buffer
This RFC is to introduce the 2nd swiotlb buffer for 64-bit DMA access. The prototype is based on v5.11-rc6. The state of the art swiotlb pre-allocates <=32-bit memory in order to meet the DMA mask requirement for some 32-bit legacy device. Considering most devices nowadays support 64-bit DMA and IOMMU is available, the swiotlb is not used for most of times, except: 1. The xen PVM domain requires the DMA addresses to both (1) <= the device dma mask, and (2) continuous in machine address. Therefore, the 64-bit device may still require swiotlb on PVM domain. 2. From source code the AMD SME/SEV will enable SWIOTLB_FORCE. As a result it is always required to allocate from swiotlb buffer even the device dma mask is 64-bit. sme_early_init() -> if (sev_active()) swiotlb_force = SWIOTLB_FORCE; Therefore, this RFC introduces the 2nd swiotlb buffer for 64-bit DMA access. For instance, the swiotlb_tbl_map_single() allocates from the 2nd 64-bit buffer if the device DMA mask min_not_zero(*hwdev->dma_mask, hwdev->bus_dma_limit) is 64-bit. With the RFC, the Xen/AMD will be able to allocate >4GB swiotlb buffer. With it being 64-bit, you can (not in this patch set but certainly possible) allocate this at runtime. Meaning the size could change depending on the device MMIO buffers, etc. I have tested the patch set on Xen PVM dom0 boot via QEMU. The dom0 is boot via: qemu-system-x86_64 -smp 8 -m 20G -enable-kvm -vnc :9 \ -net nic -net user,hostfwd=tcp::5029-:22 \ -hda disk.img \ -device nvme,drive=nvme0,serial=deudbeaf1,max_ioqpairs=16 \ -drive file=test.qcow2,if=none,id=nvme0 \ -serial stdio The "swiotlb=65536,1048576,force" is to configure 32-bit swiotlb as 128MB and 64-bit swiotlb as 2048MB. The swiotlb is enforced. vm# cat /proc/cmdline placeholder root=UUID=4e942d60-c228-4caf-b98e-f41c365d9703 ro text swiotlb=65536,1048576,force quiet splash [5.119877] Booting paravirtualized kernel on Xen ... ... [5.190423] software IO TLB: Low Mem mapped [mem 0x000234e0-0x00023ce0] (128MB) [6.276161] software IO TLB: High Mem mapped [mem 0x000166f33000-0x0001e6f33000] (2048MB) 0x000234e0 is mapped to 0x001c (32-bit machine address) 0x00023ce0-1 is mapped to 0x0ff3 (32-bit machine address) 0x000166f33000 is mapped to 0x0004b728 (64-bit machine address) 0x0001e6f33000-1 is mapped to 0x00033a07 (64-bit machine address) While running fio for emulated-NVMe, the swiotlb is allocating from 64-bit io_tlb_used-highmem. vm# cat /sys/kernel/debug/swiotlb/io_tlb_nslabs 65536 vm# cat /sys/kernel/debug/swiotlb/io_tlb_used 258 vm# cat /sys/kernel/debug/swiotlb/io_tlb_nslabs-highmem 1048576 vm# cat /sys/kernel/debug/swiotlb/io_tlb_used-highmem 58880 I also tested virtio-scsi (with "disable-legacy=on,iommu_platform=true") on VM with AMD SEV enabled. qemu-system-x86_64 -enable-kvm -machine q35 -smp 36 -m 20G \ -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.pure-efi.fd,readonly \ -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.fd \ -hda ol7-uefi.qcow2 -serial stdio -vnc :9 \ -net nic -net user,hostfwd=tcp::5029-:22 \ -cpu EPYC -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1 \ -machine memory-encryption=sev0 \ -device virtio-scsi-pci,id=scsi,disable-legacy=on,iommu_platform=true \ -device scsi-hd,drive=disk0 \ -drive file=test.qcow2,if=none,id=disk0,format=qcow2 The "swiotlb=65536,1048576" is to configure 32-bit swiotlb as 128MB and 64-bit swiotlb as 2048MB. We do not need to force swiotlb because AMD SEV will set SWIOTLB_FORCE. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-5.11.0-rc6swiotlb+ root=/dev/mapper/ol-root ro crashkernel=auto rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rhgb quiet LANG=en_US.UTF-8 swiotlb=65536,1048576 [0.729790] AMD Memory Encryption Features active: SEV ... ... [2.113147] software IO TLB: Low Mem mapped [mem 0x73e1e000-0x7be1e000] (128MB) [2.113151] software IO TLB: High Mem mapped [mem 0x0004e840-0x00056840] (2048MB) While running fio for virtio-scsi, the swiotlb is allocating from 64-bit io_tlb_used-highmem. vm# cat /sys/kernel/debug/swiotlb/io_tlb_nslabs 65536 vm# cat /sys/kernel/debug/swiotlb/io_tlb_used 0 vm# cat /sys/kernel/debug/swiotlb/io_tlb_nslabs-highmem 1048576 vm# cat /sys/kernel/debug/swiotlb/io_tlb_used-highmem 64647 Please let me know if there is any feedback for this idea and RFC. Dongli Zhang (6): swiotlb: define new enumerated type swiotlb: convert variables to arrays swiotlb: introduce swiotlb_get_type() to calculate swiotlb buffer type swiotlb: enable 64-bit swiotlb xen-swiotlb: convert variables to arrays xen-swiotlb: enable 64-bit xen-swiotlb arch/mips/cavium-octeon/dma-octeon.c | 3 +- arch/powerpc/kernel/dma-swiotlb.c| 2 +- arch/powerpc/platforms/pseries/svm.c | 8 +- arch/x86/kernel/pci-swiotlb.c| 5 +- arch/x86/pci/sta2x11-fixup.c
[PATCH RFC v1 2/6] swiotlb: convert variables to arrays
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and io_tlb_end
- io_tlb_nslabs and io_tlb_used
- io_tlb_list
- io_tlb_index
- max_segment
- io_tlb_orig_addr
- no_iotlb_memory
There is no functional change and this is to prepare to enable 64-bit
swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
arch/powerpc/platforms/pseries/svm.c | 6 +-
drivers/xen/swiotlb-xen.c| 4 +-
include/linux/swiotlb.h | 5 +-
kernel/dma/swiotlb.c | 257 ++-
4 files changed, 140 insertions(+), 132 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
index 7b739cc7a8a9..9f8842d0da1f 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -55,9 +55,9 @@ void __init svm_swiotlb_init(void)
if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, false))
return;
- if (io_tlb_start)
- memblock_free_early(io_tlb_start,
- PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
+ if (io_tlb_start[SWIOTLB_LO])
+ memblock_free_early(io_tlb_start[SWIOTLB_LO],
+ PAGE_ALIGN(io_tlb_nslabs[SWIOTLB_LO] <<
IO_TLB_SHIFT));
panic("SVM: Cannot allocate SWIOTLB buffer");
}
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 2b385c1b4a99..3261880ad859 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -192,8 +192,8 @@ int __ref xen_swiotlb_init(int verbose, bool early)
/*
* IO TLB memory already allocated. Just use it.
*/
- if (io_tlb_start != 0) {
- xen_io_tlb_start = phys_to_virt(io_tlb_start);
+ if (io_tlb_start[SWIOTLB_LO] != 0) {
+ xen_io_tlb_start = phys_to_virt(io_tlb_start[SWIOTLB_LO]);
goto end;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index ca125c1b1281..777046cd4d1b 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -76,11 +76,12 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t phys,
#ifdef CONFIG_SWIOTLB
extern enum swiotlb_force swiotlb_force;
-extern phys_addr_t io_tlb_start, io_tlb_end;
+extern phys_addr_t io_tlb_start[], io_tlb_end[];
static inline bool is_swiotlb_buffer(phys_addr_t paddr)
{
- return paddr >= io_tlb_start && paddr < io_tlb_end;
+ return paddr >= io_tlb_start[SWIOTLB_LO] &&
+ paddr < io_tlb_end[SWIOTLB_LO];
}
void __init swiotlb_exit(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 7c42df6e6100..1fbb65daa2dd 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -69,38 +69,38 @@ enum swiotlb_force swiotlb_force;
* swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
* API.
*/
-phys_addr_t io_tlb_start, io_tlb_end;
+phys_addr_t io_tlb_start[SWIOTLB_MAX], io_tlb_end[SWIOTLB_MAX];
/*
* The number of IO TLB blocks (in groups of 64) between io_tlb_start and
* io_tlb_end. This is command line adjustable via setup_io_tlb_npages.
*/
-static unsigned long io_tlb_nslabs;
+static unsigned long io_tlb_nslabs[SWIOTLB_MAX];
/*
* The number of used IO TLB block
*/
-static unsigned long io_tlb_used;
+static unsigned long io_tlb_used[SWIOTLB_MAX];
/*
* This is a free list describing the number of free entries available from
* each index
*/
-static unsigned int *io_tlb_list;
-static unsigned int io_tlb_index;
+static unsigned int *io_tlb_list[SWIOTLB_MAX];
+static unsigned int io_tlb_index[SWIOTLB_MAX];
/*
* Max segment that we can provide which (if pages are contingous) will
* not be bounced (unless SWIOTLB_FORCE is set).
*/
-static unsigned int max_segment;
+static unsigned int max_segment[SWIOTLB_MAX];
/*
* We need to save away the original address corresponding to a mapped entry
* for the sync operations.
*/
#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
-static phys_addr_t *io_tlb_orig_addr;
+static phys_addr_t *io_tlb_orig_addr[SWIOTLB_MAX];
/*
* Protect the above data structures in the map and unmap calls
@@ -113,9 +113,9 @@ static int __init
setup_io_tlb_npages(char *str)
{
if (isdigit(*str)) {
- io_tlb_nslabs = simple_strtoul(str, &str, 0);
+ io_tlb_nslabs[SWIOTLB_LO] = simple_strtoul(str, &str, 0);
/* avoid tail segment of size < IO_TLB_SEGSIZE */
- io_tlb_nslabs = ALIGN(io_tlb_nslabs, IO_TLB_SEGSIZE);
+ io_tlb_nslabs[SWIOTLB_LO] = ALIGN(io_tlb_nslabs[SWIOTLB_LO],
IO_TLB_SEGSIZE);
}
if (*str == ',')
++str;
@@ -123,40 +123,40 @@ setup_io_tlb_npages(char *str)
swiotlb_force = SWIOTLB_FORCE;
} else if (!strcmp(str, "noforce")) {
[PATCH RFC v1 1/6] swiotlb: define new enumerated type
This is just to define new enumerated type without functional change.
The 'SWIOTLB_LO' is to index legacy 32-bit swiotlb buffer, while the
'SWIOTLB_HI' is to index the 64-bit buffer.
This is to prepare to enable 64-bit swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
include/linux/swiotlb.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index d9c9fc9ca5d2..ca125c1b1281 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -17,6 +17,12 @@ enum swiotlb_force {
SWIOTLB_NO_FORCE, /* swiotlb=noforce */
};
+enum swiotlb_t {
+ SWIOTLB_LO,
+ SWIOTLB_HI,
+ SWIOTLB_MAX,
+};
+
/*
* Maximum allowable number of contiguous slabs to map,
* must be a power of 2. What is the appropriate value ?
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH RFC v1 3/6] swiotlb: introduce swiotlb_get_type() to calculate swiotlb buffer type
This patch introduces swiotlb_get_type() in order to calculate which
swiotlb buffer the given DMA address is belong to.
This is to prepare to enable 64-bit swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
include/linux/swiotlb.h | 14 ++
kernel/dma/swiotlb.c| 2 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 777046cd4d1b..3d5980d77810 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -3,6 +3,7 @@
#define __LINUX_SWIOTLB_H
#include
+#include
#include
#include
#include
@@ -23,6 +24,8 @@ enum swiotlb_t {
SWIOTLB_MAX,
};
+extern int swiotlb_nr;
+
/*
* Maximum allowable number of contiguous slabs to map,
* must be a power of 2. What is the appropriate value ?
@@ -84,6 +87,17 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
paddr < io_tlb_end[SWIOTLB_LO];
}
+static inline int swiotlb_get_type(phys_addr_t paddr)
+{
+ int i;
+
+ for (i = 0; i < swiotlb_nr; i++)
+ if (paddr >= io_tlb_start[i] && paddr < io_tlb_end[i])
+ return i;
+
+ return -ENOENT;
+}
+
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fbb65daa2dd..c91d3d2c3936 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -109,6 +109,8 @@ static DEFINE_SPINLOCK(io_tlb_lock);
static int late_alloc;
+int swiotlb_nr = 1;
+
static int __init
setup_io_tlb_npages(char *str)
{
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote: > > On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: > > On 2021-02-01 23:50, Jordan Crouse wrote: > > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > > > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan > > > > > > > wrote: > > > > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > > > > > > > On reflection, I'm a bit worried about exposing this because I > > > > > > > think it > > > > > > > will > > > > > > > introduce a mismatched virtual alias with the CPU (we don't even > > > > > > > have a > > > > > > > MAIR > > > > > > > set up for this memory type). Now, we also have that issue for > > > > > > > the PTW, > > > > > > > but > > > > > > > since we always use cache maintenance (i.e. the streaming API) for > > > > > > > publishing the page-tables to a non-coheren walker, it works out. > > > > > > > However, > > > > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API > > > > > > > coherent > > > > > > > allocation, then they're potentially in for a nasty surprise due > > > > > > > to the > > > > > > > mismatched outer-cacheability attributes. > > > > > > > > > > > > > > > > > > > Can't we add the syscached memory type similar to what is done on > > > > > > android? > > > > > > > > > > Maybe. How does the GPU driver map these things on the CPU side? > > > > > > > > Currently we use writecombine mappings for everything, although there > > > > are some cases that we'd like to use cached (but have not merged > > > > patches that would give userspace a way to flush/invalidate) > > > > > > > > > > LLC/system cache doesn't have a relationship with the CPU cache. Its > > > just a > > > little accelerator that sits on the connection from the GPU to DDR and > > > caches > > > accesses. The hint that Sai is suggesting is used to mark the buffers as > > > 'no-write-allocate' to prevent GPU write operations from being cached in > > > the LLC > > > which a) isn't interesting and b) takes up cache space for read > > > operations. > > > > > > Its easiest to think of the LLC as a bonus accelerator that has no cost > > > for > > > us to use outside of the unfortunate per buffer hint. > > > > > > We do have to worry about the CPU cache w.r.t I/O coherency (which is a > > > different hint) and in that case we have all of concerns that Will > > > identified. > > > > > > > For mismatched outer cacheability attributes which Will mentioned, I was > > referring to [1] in android kernel. > > I've lost track of the conversation here :/ > > When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped > into the CPU and with what attributes? Rob said "writecombine for > everything" -- does that mean ioremap_wc() / MEMREMAP_WC? Currently userspace asks for everything WC, so pgprot_writecombine() The kernel doesn't enforce this, but so far provides no UAPI to do anything useful with non-coherent cached mappings (although there is interest to support this) BR, -R > Finally, we need to be careful when we use the word "hint" as "allocation > hint" has a specific meaning in the architecture, and if we only mismatch on > those then we're actually ok. But I think IOMMU_LLC is more than just a > hint, since it actually drives eviction policy (i.e. it enables writeback). > > Sorry for the pedantry, but I just want to make sure we're all talking > about the same things! > > Cheers, > > Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] iommu/io-pgtable-arm: Add IOMMU_LLC page protection flag
On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote: > On 2021-02-01 23:50, Jordan Crouse wrote: > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote: > > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote: > > > > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote: > > > > > On 2021-01-29 14:35, Will Deacon wrote: > > > > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote: > > > > > > > +#define IOMMU_LLC(1 << 6) > > > > > > > > > > > > On reflection, I'm a bit worried about exposing this because I > > > > > > think it > > > > > > will > > > > > > introduce a mismatched virtual alias with the CPU (we don't even > > > > > > have a > > > > > > MAIR > > > > > > set up for this memory type). Now, we also have that issue for the > > > > > > PTW, > > > > > > but > > > > > > since we always use cache maintenance (i.e. the streaming API) for > > > > > > publishing the page-tables to a non-coheren walker, it works out. > > > > > > However, > > > > > > if somebody expects IOMMU_LLC to be coherent with a DMA API coherent > > > > > > allocation, then they're potentially in for a nasty surprise due to > > > > > > the > > > > > > mismatched outer-cacheability attributes. > > > > > > > > > > > > > > > > Can't we add the syscached memory type similar to what is done on > > > > > android? > > > > > > > > Maybe. How does the GPU driver map these things on the CPU side? > > > > > > Currently we use writecombine mappings for everything, although there > > > are some cases that we'd like to use cached (but have not merged > > > patches that would give userspace a way to flush/invalidate) > > > > > > > LLC/system cache doesn't have a relationship with the CPU cache. Its > > just a > > little accelerator that sits on the connection from the GPU to DDR and > > caches > > accesses. The hint that Sai is suggesting is used to mark the buffers as > > 'no-write-allocate' to prevent GPU write operations from being cached in > > the LLC > > which a) isn't interesting and b) takes up cache space for read > > operations. > > > > Its easiest to think of the LLC as a bonus accelerator that has no cost > > for > > us to use outside of the unfortunate per buffer hint. > > > > We do have to worry about the CPU cache w.r.t I/O coherency (which is a > > different hint) and in that case we have all of concerns that Will > > identified. > > > > For mismatched outer cacheability attributes which Will mentioned, I was > referring to [1] in android kernel. I've lost track of the conversation here :/ When the GPU has a buffer mapped with IOMMU_LLC, is the buffer also mapped into the CPU and with what attributes? Rob said "writecombine for everything" -- does that mean ioremap_wc() / MEMREMAP_WC? Finally, we need to be careful when we use the word "hint" as "allocation hint" has a specific meaning in the architecture, and if we only mismatch on those then we're actually ok. But I think IOMMU_LLC is more than just a hint, since it actually drives eviction policy (i.e. it enables writeback). Sorry for the pedantry, but I just want to make sure we're all talking about the same things! Cheers, Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/3] iommu/arm-smmu-v3: Add debug interfaces for SMMUv3
On Wed, Feb 03, 2021 at 11:15:18AM +0800, Zhou Wang wrote: > On 2021/1/29 17:06, Zhou Wang wrote: > > This RFC series is the followed patch of this discussion: > > https://www.spinics.net/lists/arm-kernel/msg866187.html. > > > > Currently there is no debug interface about SMMUv3 driver, which makes it > > not convenient when we want to dump some information, like the value of > > CD/STE, S1/S2 page table, SMMU registers or cmd/event/pri queues. > > > > This series tries to add support of dumping CD/STE and page table. The > > interface design is that user sets device/pasid firstly by sysfs files > > and then read related sysfs file to get information: > > > > (currently only support PCI device) > > echo ::. > /sys/kernel/debug/iommu/smmuv3/pci_dev > > echo > /sys/kernel/debug/iommu/smmuv3/pasid > > > > Then value in CD and STE can be got by: > > cat /sys/kernel/debug/iommu/smmuv3/ste > > cat /sys/kernel/debug/iommu/smmuv3/cd > > > > S1 and S2 page tables can be got by: > > cat /sys/kernel/debug/iommu/smmuv3/pt_dump_s1 > > cat /sys/kernel/debug/iommu/smmuv3/pt_dump_s2 > > > > For STE, CD and page table, related device and pasid are set in pci_dev > > and pasid files as above. > > > > First and second patch export some help functions or macros in arm-smmu-v3 > > and io-pgtable-arm codes, so we can reuse them in debugfs.c. As a RFC, this > > series does not go further to dump SMMU registers and cmd/event/pri queues. > > I am not sure this series is in the right way, so let's post it out and > > have a > > discussion. Looking forward to any feedback. > > > > Zhou Wang (3): > > iommu/arm-smmu-v3: Export cd/ste get functions > > iommu/io-pgtable: Export page table walk needed functions and macros > > iommu/arm-smmu-v3: Add debug interfaces for SMMUv3 > > > > drivers/iommu/Kconfig | 11 + > > drivers/iommu/arm/arm-smmu-v3/Makefile | 1 + > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 10 +- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 10 + > > drivers/iommu/arm/arm-smmu-v3/debugfs.c | 398 > > > > drivers/iommu/io-pgtable-arm.c | 47 +--- > > drivers/iommu/io-pgtable-arm.h | 43 +++ > > 7 files changed, 475 insertions(+), 45 deletions(-) > > create mode 100644 drivers/iommu/arm/arm-smmu-v3/debugfs.c > > > > Any comments about this series? Truthfully, I don't really see the use in dumping the state of the SMMU data structures. They're not especially dynamic, and there are higher level ways to determine how devices map to groups etc. However, I can see some utility in dumping the page-tables. We have that functionality for the CPU side via /sys/kernel/debug/kernel_page_tables, so something similar in the io-pgtable code could be quite neat. In particular, the logic to expose things in debugfs and drive the dumping could be agnostic of the page-table format, while the formats themselves coule implement optional callback(s) to return the data. Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
On Tue, Feb 02, 2021 at 04:33:56PM -0800, Stephen Boyd wrote: > Quoting Rob Herring (2021-02-02 12:55:42) > > > > diff --git > > a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > > > b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > index fa0ee03a527f..53cc6df0df96 100644 > > --- > > a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > +++ > > b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > @@ -18,7 +18,7 @@ properties: > > const: 1 > > > >compatible: > > -const: allwinner,sun9i-a80-usb-clocks > > +const: allwinner,sun9i-a80-usb-clks > > Should the file name change too? Yes, I'll fix that while applying. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 12/12] irqchip: Add IMS (Interrupt Message Store) driver
From: Thomas Gleixner
Generic IMS(Interrupt Message Store) irq chips and irq domain
implementations for IMS based devices which store the interrupt messages
in an array in device memory.
Allocation and freeing of interrupts happens via the generic
msi_domain_alloc/free_irqs() interface. No special purpose IMS magic
required as long as the interrupt domain is stored in the underlying
device struct. The irq_set_auxdata() is used to program the pasid into
the IMS entry.
[Megha : Fixed compile time errors
Added necessary dependencies to IMS_MSI_ARRAY config
Fixed polarity of IMS_VECTOR_CTRL
Added reads after writes to flush writes to device
Added set_desc ops to IMS msi domain ops
Tested the IMS infrastructure with the IDXD driver]
Reviewed-by: Tony Luck
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
drivers/irqchip/Kconfig | 14 +++
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-ims-msi.c | 211
include/linux/irqchip/irq-ims-msi.h | 68
4 files changed, 294 insertions(+)
create mode 100644 drivers/irqchip/irq-ims-msi.c
create mode 100644 include/linux/irqchip/irq-ims-msi.h
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b147f22..b50c821 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -590,4 +590,18 @@ config MST_IRQ
help
Support MStar Interrupt Controller.
+config IMS_MSI
+ depends on PCI
+ select DEVICE_MSI
+ bool
+
+config IMS_MSI_ARRAY
+ bool "IMS Interrupt Message Store MSI controller for device memory
storage arrays"
+ depends on PCI
+ select IMS_MSI
+ select GENERIC_MSI_IRQ_DOMAIN
+ help
+ Support for IMS Interrupt Message Store MSI controller
+ with IMS slot storage in a slot array in device memory
+
endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 0ac93bf..658a6bd 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_LOONGSON_PCH_PIC) +=
irq-loongson-pch-pic.o
obj-$(CONFIG_LOONGSON_PCH_MSI) += irq-loongson-pch-msi.o
obj-$(CONFIG_MST_IRQ) += irq-mst-intc.o
obj-$(CONFIG_SL28CPLD_INTC)+= irq-sl28cpld.o
+obj-$(CONFIG_IMS_MSI) += irq-ims-msi.o
diff --git a/drivers/irqchip/irq-ims-msi.c b/drivers/irqchip/irq-ims-msi.c
new file mode 100644
index 000..fa23207
--- /dev/null
+++ b/drivers/irqchip/irq-ims-msi.c
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: GPL-2.0
+// (C) Copyright 2021 Thomas Gleixner
+/*
+ * Shared interrupt chips and irq domains for IMS devices
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#ifdef CONFIG_IMS_MSI_ARRAY
+
+struct ims_array_data {
+ struct ims_array_info info;
+ unsigned long map[0];
+};
+
+static inline void iowrite32_and_flush(u32 value, void __iomem *addr)
+{
+ iowrite32(value, addr);
+ ioread32(addr);
+}
+
+static void ims_array_mask_irq(struct irq_data *data)
+{
+ struct msi_desc *desc = irq_data_get_msi_desc(data);
+ struct ims_slot __iomem *slot = desc->device_msi.priv_iomem;
+ u32 __iomem *ctrl = &slot->ctrl;
+
+ iowrite32_and_flush(ioread32(ctrl) | IMS_CTRL_VECTOR_MASKBIT, ctrl);
+}
+
+static void ims_array_unmask_irq(struct irq_data *data)
+{
+ struct msi_desc *desc = irq_data_get_msi_desc(data);
+ struct ims_slot __iomem *slot = desc->device_msi.priv_iomem;
+ u32 __iomem *ctrl = &slot->ctrl;
+
+ iowrite32_and_flush(ioread32(ctrl) & ~IMS_CTRL_VECTOR_MASKBIT, ctrl);
+}
+
+static void ims_array_write_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ struct msi_desc *desc = irq_data_get_msi_desc(data);
+ struct ims_slot __iomem *slot = desc->device_msi.priv_iomem;
+
+ iowrite32(msg->address_lo, &slot->address_lo);
+ iowrite32(msg->address_hi, &slot->address_hi);
+ iowrite32_and_flush(msg->data, &slot->data);
+}
+
+static int ims_array_set_auxdata(struct irq_data *data, unsigned int which,
+u64 auxval)
+{
+ struct msi_desc *desc = irq_data_get_msi_desc(data);
+ struct ims_slot __iomem *slot = desc->device_msi.priv_iomem;
+ u32 val, __iomem *ctrl = &slot->ctrl;
+
+ if (which != IMS_AUXDATA_CONTROL_WORD)
+ return -EINVAL;
+ if (auxval & ~(u64)IMS_CONTROL_WORD_AUXMASK)
+ return -EINVAL;
+
+ val = ioread32(ctrl) & IMS_CONTROL_WORD_IRQMASK;
+ iowrite32_and_flush(val | (u32)auxval, ctrl);
+ return 0;
+}
+
+static const struct irq_chip ims_array_msi_controller = {
+ .name = "IMS",
+ .irq_mask = ims_array_mask_irq,
+ .irq_unmask = ims_array_unmask_irq,
+ .irq_write_msi_msg = ims_array_write_msi_msg,
+ .irq_set_auxdat
[PATCH 06/12] platform-msi: Add device MSI infrastructure
From: Thomas Gleixner
Add device specific MSI domain infrastructure for devices which have their
own resource management and interrupt chip. These devices are not related
to PCI and contrary to platform MSI they do not share a common resource and
interrupt chip. They provide their own domain specific resource management
and interrupt chip.
This utilizes the new alloc/free override in a non evil way which avoids
having yet another set of specialized alloc/free functions. Just using
msi_domain_alloc/free_irqs() is sufficient
While initially it was suggested and tried to piggyback device MSI on
platform MSI, the better variant is to reimplement platform MSI on top of
device MSI.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
drivers/base/platform-msi.c | 131
include/linux/irqdomain.h | 1 +
include/linux/msi.h | 24
kernel/irq/Kconfig | 4 ++
4 files changed, 160 insertions(+)
diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index 9d9ccfc..6127b3b 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -419,3 +419,134 @@ int platform_msi_domain_alloc(struct irq_domain *domain,
unsigned int virq,
return err;
}
+
+#ifdef CONFIG_DEVICE_MSI
+/*
+ * Device specific MSI domain infrastructure for devices which have their
+ * own resource management and interrupt chip. These devices are not
+ * related to PCI and contrary to platform MSI they do not share a common
+ * resource and interrupt chip. They provide their own domain specific
+ * resource management and interrupt chip.
+ */
+
+static void device_msi_free_msi_entries(struct device *dev)
+{
+ struct list_head *msi_list = dev_to_msi_list(dev);
+ struct msi_desc *entry, *tmp;
+
+ list_for_each_entry_safe(entry, tmp, msi_list, list) {
+ list_del(&entry->list);
+ free_msi_entry(entry);
+ }
+}
+
+/**
+ * device_msi_free_irqs - Free MSI interrupts assigned to a device
+ * @dev: Pointer to the device
+ *
+ * Frees the interrupt and the MSI descriptors.
+ */
+static void device_msi_free_irqs(struct irq_domain *domain, struct device *dev)
+{
+ __msi_domain_free_irqs(domain, dev);
+ device_msi_free_msi_entries(dev);
+}
+
+/**
+ * device_msi_alloc_irqs - Allocate MSI interrupts for a device
+ * @dev: Pointer to the device
+ * @nvec: Number of vectors
+ *
+ * Allocates the required number of MSI descriptors and the corresponding
+ * interrupt descriptors.
+ */
+static int device_msi_alloc_irqs(struct irq_domain *domain, struct device
*dev, int nvec)
+{
+ int i, ret = -ENOMEM;
+
+ for (i = 0; i < nvec; i++) {
+ struct msi_desc *entry = alloc_msi_entry(dev, 1, NULL);
+
+ if (!entry)
+ goto fail;
+ list_add_tail(&entry->list, dev_to_msi_list(dev));
+ }
+
+ ret = __msi_domain_alloc_irqs(domain, dev, nvec);
+ if (!ret)
+ return 0;
+fail:
+ device_msi_free_msi_entries(dev);
+ return ret;
+}
+
+static void device_msi_update_dom_ops(struct msi_domain_info *info)
+{
+ if (!info->ops->domain_alloc_irqs)
+ info->ops->domain_alloc_irqs = device_msi_alloc_irqs;
+ if (!info->ops->domain_free_irqs)
+ info->ops->domain_free_irqs = device_msi_free_irqs;
+ if (!info->ops->msi_prepare)
+ info->ops->msi_prepare = arch_msi_prepare;
+}
+
+/**
+ * device_msi_create_msi_irq_domain - Create an irq domain for devices
+ * @fwnode:Firmware node of the interrupt controller
+ * @info: MSI domain info to configure the new domain
+ * @parent:Parent domain
+ */
+struct irq_domain *device_msi_create_irq_domain(struct fwnode_handle *fn,
+ struct msi_domain_info *info,
+ struct irq_domain *parent)
+{
+ struct irq_domain *domain;
+
+ if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
+ platform_msi_update_chip_ops(info);
+
+ if (info->flags & MSI_FLAG_USE_DEF_DOM_OPS)
+ device_msi_update_dom_ops(info);
+
+ msi_domain_set_default_info_flags(info);
+
+ domain = msi_create_irq_domain(fn, info, parent);
+ if (domain)
+ irq_domain_update_bus_token(domain, DOMAIN_BUS_DEVICE_MSI);
+ return domain;
+}
+
+#ifdef CONFIG_PCI
+#include
+
+/**
+ * pci_subdevice_msi_create_irq_domain - Create an irq domain for subdevices
+ * @pdev: Pointer to PCI device for which the subdevice domain is created
+ * @info: MSI domain info to configure the new domain
+ */
+struct irq_domain *pci_subdevice_msi_create_irq_domain(struct pci_dev *pdev,
+ struct msi_domain_info
*info)
+{
+ struct irq_domain *domain, *pdev_msi;
+ struct fwnode_handle *fn;
+
+ /*
+*
[PATCH 09/12] iommu/vt-d: Add DEV-MSI support
Add required support in the interrupt remapping driver for devices which generate dev-msi interrupts and use the intel remapping domain as the parent domain. Set the source-id of all dev-msi interrupt requests to the parent PCI device associated with it. Reviewed-by: Tony Luck Signed-off-by: Megha Dey --- drivers/iommu/intel/irq_remapping.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/irq_remapping.c b/drivers/iommu/intel/irq_remapping.c index 685200a..18f1b53 100644 --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -1278,6 +1278,9 @@ static void intel_irq_remapping_prepare_irte(struct intel_ir_data *data, case X86_IRQ_ALLOC_TYPE_PCI_MSIX: set_msi_sid(irte, msi_desc_to_pci_dev(info->desc)); break; + case X86_IRQ_ALLOC_TYPE_DEV_MSI: + set_msi_sid(irte, to_pci_dev(info->desc->dev->parent)); + break; default: BUG_ON(1); break; @@ -1321,7 +1324,8 @@ static int intel_irq_remapping_alloc(struct irq_domain *domain, if (!info || !iommu) return -EINVAL; if (nr_irqs > 1 && info->type != X86_IRQ_ALLOC_TYPE_PCI_MSI && - info->type != X86_IRQ_ALLOC_TYPE_PCI_MSIX) + info->type != X86_IRQ_ALLOC_TYPE_PCI_MSIX && + info->type != X86_IRQ_ALLOC_TYPE_DEV_MSI) return -EINVAL; /* -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 11/12] platform-msi: Add platform check for subdevice irq domain
From: Lu Baolu
The pci_subdevice_msi_create_irq_domain() should fail if the underlying
platform is not able to support IMS (Interrupt Message Storage). Otherwise,
the isolation of interrupt is not guaranteed.
For x86, IMS is only supported on bare metal for now. We could enable it
in the virtualization environments in the future if interrupt HYPERCALL
domain is supported or the hardware has the capability of interrupt
isolation for subdevices.
Cc: David Woodhouse
Cc: Leon Romanovsky
Cc: Kevin Tian
Suggested-by: Thomas Gleixner
Link: https://lore.kernel.org/linux-pci/87pn4nk7nn@nanos.tec.linutronix.de/
Link: https://lore.kernel.org/linux-pci/877dqrnzr3@nanos.tec.linutronix.de/
Link: https://lore.kernel.org/linux-pci/877dqqmc2h@nanos.tec.linutronix.de/
Signed-off-by: Lu Baolu
Signed-off-by: Megha Dey
---
arch/x86/pci/common.c | 74 +
drivers/base/platform-msi.c | 8 +
include/linux/msi.h | 1 +
3 files changed, 83 insertions(+)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 3507f45..263ccf6 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -12,6 +12,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -724,3 +726,75 @@ struct pci_dev *pci_real_dma_dev(struct pci_dev *dev)
return dev;
}
#endif
+
+#ifdef CONFIG_DEVICE_MSI
+/*
+ * We want to figure out which context we are running in. But the hardware
+ * does not introduce a reliable way (instruction, CPUID leaf, MSR, whatever)
+ * which can be manipulated by the VMM to let the OS figure out where it runs.
+ * So we go with the below probably on_bare_metal() function as a replacement
+ * for definitely on_bare_metal() to go forward only for the very simple reason
+ * that this is the only option we have.
+ */
+static const char * const vmm_vendor_name[] = {
+ "QEMU", "Bochs", "KVM", "Xen", "VMware", "VMW", "VMware Inc.",
+ "innotek GmbH", "Oracle Corporation", "Parallels", "BHYVE"
+};
+
+static void read_type0_virtual_machine(const struct dmi_header *dm, void *p)
+{
+ u8 *data = (u8 *)dm + 0x13;
+
+ /* BIOS Information (Type 0) */
+ if (dm->type != 0 || dm->length < 0x14)
+ return;
+
+ /* Bit 4 of BIOS Characteristics Extension Byte 2*/
+ if (*data & BIT(4))
+ *((bool *)p) = true;
+}
+
+static bool smbios_virtual_machine(void)
+{
+ bool bit_present = false;
+
+ dmi_walk(read_type0_virtual_machine, &bit_present);
+
+ return bit_present;
+}
+
+static bool on_bare_metal(struct device *dev)
+{
+ int i;
+
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+ return false;
+
+ if (smbios_virtual_machine())
+ return false;
+
+ if (iommu_capable(dev->bus, IOMMU_CAP_VIOMMU_HINT))
+ return false;
+
+ for (i = 0; i < ARRAY_SIZE(vmm_vendor_name); i++)
+ if (dmi_match(DMI_SYS_VENDOR, vmm_vendor_name[i]))
+ return false;
+
+ pr_info("System running on bare metal, report to bugzilla.kernel.org if
not the case.");
+
+ return true;
+}
+
+bool arch_support_pci_device_ims(struct pci_dev *pdev)
+{
+ /*
+* When we are running in a VMM context, the device IMS could only be
+* enabled when the underlying hardware supports interrupt isolation
+* of the subdevice, or any mechanism (trap, hypercall) is added so
+* that changes in the interrupt message store could be managed by the
+* VMM. For now, we only support the device IMS when we are running on
+* the bare metal.
+*/
+ return on_bare_metal(&pdev->dev);
+}
+#endif
diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index 6127b3b..d5ae26f 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -519,6 +519,11 @@ struct irq_domain *device_msi_create_irq_domain(struct
fwnode_handle *fn,
#ifdef CONFIG_PCI
#include
+bool __weak arch_support_pci_device_ims(struct pci_dev *pdev)
+{
+ return false;
+}
+
/**
* pci_subdevice_msi_create_irq_domain - Create an irq domain for subdevices
* @pdev: Pointer to PCI device for which the subdevice domain is created
@@ -530,6 +535,9 @@ struct irq_domain
*pci_subdevice_msi_create_irq_domain(struct pci_dev *pdev,
struct irq_domain *domain, *pdev_msi;
struct fwnode_handle *fn;
+ if (!arch_support_pci_device_ims(pdev))
+ return NULL;
+
/*
* Retrieve the MSI domain of the underlying PCI device's MSI
* domain. The PCI device domain's parent domain is also the parent
diff --git a/include/linux/msi.h b/include/linux/msi.h
index a6b419d..fa02542 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -478,6 +478,7 @@ struct irq_domain *device_msi_create_irq_domain(struct
fwnode_handle *fn,
struct irq_doma
[PATCH 02/12] x86/msi: Rename and rework pci_msi_prepare() to cover non-PCI MSI
From: Thomas Gleixner
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture
in the generic MSI header.
One arch specific function for MSI support is truly enough.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
arch/x86/include/asm/msi.h | 4 +++-
arch/x86/kernel/apic/msi.c | 27 ---
drivers/pci/controller/pci-hyperv.c | 2 +-
include/linux/msi.h | 4
4 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index b85147d..9bd214e 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -6,9 +6,11 @@
typedef struct irq_alloc_info msi_alloc_info_t;
-int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+int x86_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
msi_alloc_info_t *arg);
+#define arch_msi_prepare x86_msi_prepare
+
/* Structs and defines for the X86 specific MSI message format */
typedef struct x86_msi_data {
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 44ebe25..84b16c7 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -153,26 +153,39 @@ static struct irq_chip pci_msi_controller = {
.flags = IRQCHIP_SKIP_SET_WAKE,
};
-int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
- msi_alloc_info_t *arg)
+static void pci_msi_prepare(struct device *dev, msi_alloc_info_t *arg)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct msi_desc *desc = first_pci_msi_entry(pdev);
+ struct msi_desc *desc = first_msi_entry(dev);
- init_irq_alloc_info(arg, NULL);
if (desc->msi_attrib.is_msix) {
arg->type = X86_IRQ_ALLOC_TYPE_PCI_MSIX;
} else {
arg->type = X86_IRQ_ALLOC_TYPE_PCI_MSI;
arg->flags |= X86_IRQ_ALLOC_CONTIGUOUS_VECTORS;
}
+}
+
+static void dev_msi_prepare(struct device *dev, msi_alloc_info_t *arg)
+{
+ arg->type = X86_IRQ_ALLOC_TYPE_DEV_MSI;
+}
+
+int x86_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+ msi_alloc_info_t *arg)
+{
+ init_irq_alloc_info(arg, NULL);
+
+ if (dev_is_pci(dev))
+ pci_msi_prepare(dev, arg);
+ else
+ dev_msi_prepare(dev, arg);
return 0;
}
-EXPORT_SYMBOL_GPL(pci_msi_prepare);
+EXPORT_SYMBOL_GPL(x86_msi_prepare);
static struct msi_domain_ops pci_msi_domain_ops = {
- .msi_prepare= pci_msi_prepare,
+ .msi_prepare= x86_msi_prepare,
};
static struct msi_domain_info pci_msi_domain_info = {
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index 6db8d96..bfb47c2 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1546,7 +1546,7 @@ static struct irq_chip hv_msi_irq_chip = {
};
static struct msi_domain_ops hv_msi_ops = {
- .msi_prepare= pci_msi_prepare,
+ .msi_prepare= arch_msi_prepare,
.msi_free = hv_msi_free,
};
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 360a0a7..89acc76 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -467,4 +467,8 @@ static inline struct irq_domain
*pci_msi_get_device_domain(struct pci_dev *pdev)
}
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
+#ifndef arch_msi_prepare
+# define arch_msi_prepare NULL
+#endif
+
#endif /* LINUX_MSI_H */
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 10/12] iommu: Add capability IOMMU_CAP_VIOMMU_HINT
From: Lu Baolu
Some IOMMU specification defines some kind of hint mechanism, through
which BIOS can imply that OS runs in a virtualized environment. For
example, the caching mode defined in VT-d spec and NpCache capability
defined in the AMD IOMMU specification. This hint could also be used
outside of the IOMMU subsystem, where it could be used with other known
means (CPUID, smbios) to sense whether Linux is running in a virtualized
environment. Add a capability bit so that it could be used there.
Signed-off-by: Lu Baolu
Signed-off-by: Megha Dey
---
drivers/iommu/amd/iommu.c| 2 ++
drivers/iommu/intel/iommu.c | 20
drivers/iommu/virtio-iommu.c | 9 +
include/linux/iommu.h| 2 ++
4 files changed, 33 insertions(+)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index f0adbc4..a851f37 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2646,6 +2646,8 @@ static bool amd_iommu_capable(enum iommu_cap cap)
return (irq_remapping_enabled == 1);
case IOMMU_CAP_NOEXEC:
return false;
+ case IOMMU_CAP_VIOMMU_HINT:
+ return amd_iommu_np_cache;
default:
break;
}
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 06b00b5..905d6aa 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5094,12 +5094,32 @@ static inline bool nested_mode_support(void)
return ret;
}
+static inline bool caching_mode_supported(void)
+{
+ struct dmar_drhd_unit *drhd;
+ struct intel_iommu *iommu;
+ bool ret = false;
+
+ rcu_read_lock();
+ for_each_active_iommu(iommu, drhd) {
+ if (cap_caching_mode(iommu->cap)) {
+ ret = true;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+
static bool intel_iommu_capable(enum iommu_cap cap)
{
if (cap == IOMMU_CAP_CACHE_COHERENCY)
return domain_update_iommu_snooping(NULL) == 1;
if (cap == IOMMU_CAP_INTR_REMAP)
return irq_remapping_enabled == 1;
+ if (cap == IOMMU_CAP_VIOMMU_HINT)
+ return caching_mode_supported();
return false;
}
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 2bfdd57..e4941ca 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -931,7 +931,16 @@ static int viommu_of_xlate(struct device *dev, struct
of_phandle_args *args)
return iommu_fwspec_add_ids(dev, args->args, 1);
}
+static bool viommu_capable(enum iommu_cap cap)
+{
+ if (cap == IOMMU_CAP_VIOMMU_HINT)
+ return true;
+
+ return false;
+}
+
static struct iommu_ops viommu_ops = {
+ .capable= viommu_capable,
.domain_alloc = viommu_domain_alloc,
.domain_free= viommu_domain_free,
.attach_dev = viommu_attach_dev,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b3f0e20..5e62bcc 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -94,6 +94,8 @@ enum iommu_cap {
transactions */
IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt isolation */
IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */
+ IOMMU_CAP_VIOMMU_HINT, /* IOMMU can detect a hit for running in
+ VM */
};
/*
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 07/12] irqdomain/msi: Provide msi_alloc/free_store() callbacks
From: Thomas Gleixner
For devices which don't have a standard storage for MSI messages like the
upcoming IMS (Interrupt Message Store) it's required to allocate storage
space before allocating interrupts and after freeing them.
This could be achieved with the existing callbacks, but that would be
awkward because they operate on msi_alloc_info_t which is not uniform
across architectures. Also these callbacks are invoked per interrupt but
the allocation might have bulk requirements depending on the device.
As such devices can operate on different architectures it is simpler to
have separate callbacks which operate on struct device. The resulting
storage information has to be stored in struct msi_desc so the underlying
irq chip implementation can retrieve it for the relevant operations.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
include/linux/msi.h | 8
kernel/irq/msi.c| 11 +++
2 files changed, 19 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index fbf2258..a6b419d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -317,6 +317,10 @@ struct msi_domain_info;
* function.
* @domain_free_irqs: Optional function to override the default free
* function.
+ * @msi_alloc_store: Optional callback to allocate storage in a device
+ * specific non-standard MSI store
+ * @msi_alloc_free:Optional callback to free storage in a device
+ * specific non-standard MSI store
*
* @get_hwirq, @msi_init and @msi_free are callbacks used by
* msi_create_irq_domain() and related interfaces
@@ -366,6 +370,10 @@ struct msi_domain_ops {
struct device *dev, int nvec);
void(*domain_free_irqs)(struct irq_domain *domain,
struct device *dev);
+ int (*msi_alloc_store)(struct irq_domain *domain,
+ struct device *dev, int nvec);
+ void(*msi_free_store)(struct irq_domain *domain,
+ struct device *dev);
};
/**
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 3697909..d70d92e 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain,
struct device *dev,
if (ret)
return ret;
+ if (ops->msi_alloc_store) {
+ ret = ops->msi_alloc_store(domain, dev, nvec);
+ if (ret)
+ return ret;
+ }
+
for_each_msi_entry(desc, dev) {
ops->set_desc(&arg, desc);
@@ -533,6 +539,8 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, struct
device *dev,
void __msi_domain_free_irqs(struct irq_domain *domain, struct device *dev)
{
+ struct msi_domain_info *info = domain->host_data;
+ struct msi_domain_ops *ops = info->ops;
struct msi_desc *desc;
for_each_msi_entry(desc, dev) {
@@ -546,6 +554,9 @@ void __msi_domain_free_irqs(struct irq_domain *domain,
struct device *dev)
desc->irq = 0;
}
}
+
+ if (ops->msi_free_store)
+ ops->msi_free_store(domain, dev);
}
/**
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 00/12] Introduce dev-msi and interrupt message store
Provide support for device specific MSI implementations for devices which have their own resource management and interrupt chip. These devices are not related to PCI and contrary to platform MSI they do not share a common resource and interrupt chip. They provide their own domain specific resource management and interrupt chip. On top of this, add support for Interrupt Message Store or IMS[1], which is a scalable device specific interrupt mechanism to support devices which may need more than 2048 interrupts. With IMS, there is theoretically no upper bound on the number of interrupts a device can support. The normal IMS use case is for guest usages but it can very well be used by host too. Introduce a generic IMS irq chip and domain which stores the interrupt messages as an array in device memory. Allocation and freeing of interrupts happens via the generic msi_domain_alloc/free_irqs() interface. One only needs to ensure the interrupt domain is stored in the underlying device struct. These patches can be divided into following steps: 1. X86 specific preparation for device MSI x86/irq: Add DEV_MSI allocation type x86/msi: Rename and rework pci_msi_prepare() to cover non-PCI MSI 2. Generic device MSI infrastructure platform-msi: Provide default irq_chip:: Ack genirq/proc: Take buslock on affinity write genirq/msi: Provide and use msi_domain_set_default_info_flags() platform-msi: Add device MSI infrastructure irqdomain/msi: Provide msi_alloc/free_store() callbacks genirq: Set auxiliary data for an interrupt 3. Interrupt Message Store (IMS) irq domain/chip implementation for device array irqchip: Add IMS (Interrupt Message Store) driver iommu/vt-d: Add DEV-MSI support 4. Add platform check for subdevice irq domain iommu: Add capability IOMMU_CAP_VIOMMU platform-msi: Add platform check for subdevice irq domain The device IMS (Interrupt Message Storage) should not be enabled in any virtualization environments unless there is a HYPERCALL domain which makes the changes in the message store monitored by the hypervisor.[2] As the initial step, we allow the IMS to be enabled only if we are running on the bare metal. It's easy to enable IMS in the virtualization environments if above preconditions are met in the future. These patches have been tested with the IDXD driver: https://github.com/intel/idxd-driver idxd-stage2.5 Most of these patches are originally by Thomas: https://lore.kernel.org/linux-hyperv/20200826111628.794979...@linutronix.de/ and are rebased on latest kernel This patches series has undergone a lot of changes since first submitted as an RFC in September 2019. I have divided the changes into 3 stages for better understanding Stage 1: Standalone RFC IMS series[3] - https://lore.kernel.org/lkml/1568338328-22458-1-git-send-email-megha@linux.intel.com/ V1: 1. Extend existing platform-msi to support IMS 2. platform_msi_domain_alloc_irqs_group is introduced to allocate IMS interrupts, tagged with a group ID. 3. To free vectors of a particular group, platform_msi_domain_free_irqs_group API in introduced Stage 2: dev-msi/IMS merged with Dave Jiang's IDXD series[2] V1: (changes from stage 1): 1. Introduced a new list for platform-msi descriptors 2. Introduced dynamic allocation for IMS interrupts 3. shifted creation of ims domain from arch/x86 to drivers/ 4. Removed arch specific callbacks 5. Introduced enum platform_msi_type 6. Added more technical details to the cover letter 7. Merge common code between platform-msi.c and ims-msi.c 8. Introduce new structures platform_msi_ops and platform_msi_funcs 9. Addressed Andriy Shevchenko's comments on RFC V1 patch series 10. Dropped the dynamic group allocation scheme. 11. Use RCU lock instead of mutex lock to protect the device list V2: 1. IMS made dev-msi 2. With recommendations from Jason/Thomas/Dan on making IMS more generic 3. Pass a non-pci generic device(struct device) for IMS management instead of mdev 4. Remove all references to mdev and symbol_get/put 5. Remove all references to IMS in common code and replace with dev-msi 6. Remove dynamic allocation of platform-msi interrupts: no groups,no new msi list or list helpers 7. Create a generic dev-msi domain with and without interrupt remapping enabled. 8. Introduce dev_msi_domain_alloc_irqs and dev_msi_domain_free_irqs apis V3: 1. No need to add support for 2 different dev-msi irq domains, a common once can be used for both the cases(with IR enabled/disabled) 2. Add arch specific function to specify additions to msi_prepare callback instead of making the callback a weak function 3. Call platform ops directly instead of a wrapper function 4. Make mask/unmask callbacks as void functions 5. dev->msi_domain should be updated at the device driver level before calling dev_msi_alloc_irqs() 6. dev_msi_alloc/free_irqs() cannot be used
[PATCH 08/12] genirq: Set auxiliary data for an interrupt
Introduce a new function pointer in the irq_chip structure(irq_set_auxdata)
which is responsible for updating data which is stored in a shared register
or data storage. For example, the idxd driver uses the auxiliary data API
to enable/set and disable PASID field that is in the IMS entry (introduced
in a later patch) and that data are not typically present in MSI entry.
Reviewed-by: Tony Luck
Signed-off-by: Megha Dey
---
include/linux/interrupt.h | 2 ++
include/linux/irq.h | 4
kernel/irq/manage.c | 32
3 files changed, 38 insertions(+)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index bb8ff90..d3f419b 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -496,6 +496,8 @@ extern int irq_get_irqchip_state(unsigned int irq, enum
irqchip_irq_state which,
extern int irq_set_irqchip_state(unsigned int irq, enum irqchip_irq_state
which,
bool state);
+int irq_set_auxdata(unsigned int irq, unsigned int which, u64 val);
+
#ifdef CONFIG_IRQ_FORCED_THREADING
# ifdef CONFIG_PREEMPT_RT
# define force_irqthreads (true)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 4aeb1c4..568cdf5 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -491,6 +491,8 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data
*d)
* irq_request_resources
* @irq_compose_msi_msg: optional to compose message content for MSI
* @irq_write_msi_msg: optional to write message content for MSI
+ * @irq_set_auxdata: Optional function to update auxiliary data e.g. in
+ * shared registers
* @irq_get_irqchip_state: return the internal state of an interrupt
* @irq_set_irqchip_state: set the internal state of a interrupt
* @irq_set_vcpu_affinity: optional to target a vCPU in a virtual machine
@@ -538,6 +540,8 @@ struct irq_chip {
void(*irq_compose_msi_msg)(struct irq_data *data, struct
msi_msg *msg);
void(*irq_write_msi_msg)(struct irq_data *data, struct
msi_msg *msg);
+ int (*irq_set_auxdata)(struct irq_data *data, unsigned int
which, u64 auxval);
+
int (*irq_get_irqchip_state)(struct irq_data *data, enum
irqchip_irq_state which, bool *state);
int (*irq_set_irqchip_state)(struct irq_data *data, enum
irqchip_irq_state which, bool state);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 85ede4e..68ff559 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -2860,3 +2860,35 @@ bool irq_check_status_bit(unsigned int irq, unsigned int
bitmask)
return res;
}
EXPORT_SYMBOL_GPL(irq_check_status_bit);
+
+/**
+ * irq_set_auxdata - Set auxiliary data
+ * @irq: Interrupt to update
+ * @which: Selector which data to update
+ * @auxval:Auxiliary data value
+ *
+ * Function to update auxiliary data for an interrupt, e.g. to update data
+ * which is stored in a shared register or data storage (e.g. IMS).
+ */
+int irq_set_auxdata(unsigned int irq, unsigned int which, u64 val)
+{
+ struct irq_desc *desc;
+ struct irq_data *data;
+ unsigned long flags;
+ int res = -ENODEV;
+
+ desc = irq_get_desc_buslock(irq, &flags, 0);
+ if (!desc)
+ return -EINVAL;
+
+ for (data = &desc->irq_data; data; data = irqd_get_parent_data(data)) {
+ if (data->chip->irq_set_auxdata) {
+ res = data->chip->irq_set_auxdata(data, which, val);
+ break;
+ }
+ }
+
+ irq_put_desc_busunlock(desc, flags);
+ return res;
+}
+EXPORT_SYMBOL_GPL(irq_set_auxdata);
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 05/12] genirq/msi: Provide and use msi_domain_set_default_info_flags()
From: Thomas Gleixner
MSI interrupts have some common flags which should be set not only for
PCI/MSI interrupts.
Move the PCI/MSI flag setting into a common function so it can be reused.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
drivers/pci/msi.c | 7 +--
include/linux/msi.h | 1 +
kernel/irq/msi.c| 24
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 3162f88..20d2512 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1492,12 +1492,7 @@ struct irq_domain *pci_msi_create_irq_domain(struct
fwnode_handle *fwnode,
if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
pci_msi_domain_update_chip_ops(info);
- info->flags |= MSI_FLAG_ACTIVATE_EARLY;
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_RESERVATION_MODE))
- info->flags |= MSI_FLAG_MUST_REACTIVATE;
-
- /* PCI-MSI is oneshot-safe */
- info->chip->flags |= IRQCHIP_ONESHOT_SAFE;
+ msi_domain_set_default_info_flags(info);
domain = msi_create_irq_domain(fwnode, info, parent);
if (!domain)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 89acc76..d7a7f7d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -448,6 +448,7 @@ int platform_msi_domain_alloc(struct irq_domain *domain,
unsigned int virq,
void platform_msi_domain_free(struct irq_domain *domain, unsigned int virq,
unsigned int nvec);
void *platform_msi_get_host_data(struct irq_domain *domain);
+void msi_domain_set_default_info_flags(struct msi_domain_info *info);
#endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index dc0e2d7..3697909 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -70,6 +70,30 @@ void get_cached_msi_msg(unsigned int irq, struct msi_msg
*msg)
EXPORT_SYMBOL_GPL(get_cached_msi_msg);
#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+void msi_domain_set_default_info_flags(struct msi_domain_info *info)
+{
+ /* Required so that a device latches a valid MSI message on startup */
+ info->flags |= MSI_FLAG_ACTIVATE_EARLY;
+
+ /*
+* Interrupt reservation mode allows to stear the MSI message of an
+* inactive device to a special (usually spurious interrupt) target.
+* This allows to prevent interrupt vector exhaustion e.g. on x86.
+* But (PCI)MSI interrupts are activated early - see above - so the
+* interrupt request/startup sequence would not try to allocate a
+* usable vector which means that the device interrupts would end
+* up on the special vector and issue spurious interrupt messages.
+* Setting the reactivation flag ensures that when the interrupt
+* is requested the activation is invoked again so that a real
+* vector can be allocated.
+*/
+ if (IS_ENABLED(CONFIG_GENERIC_IRQ_RESERVATION_MODE))
+ info->flags |= MSI_FLAG_MUST_REACTIVATE;
+
+ /* MSI is oneshot-safe at least in theory */
+ info->chip->flags |= IRQCHIP_ONESHOT_SAFE;
+}
+
static inline void irq_chip_write_msi_msg(struct irq_data *data,
struct msi_msg *msg)
{
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 01/12] x86/irq: Add DEV_MSI allocation type
From: Thomas Gleixner
For the upcoming device MSI support a new allocation type is
required.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
arch/x86/include/asm/hw_irq.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index d465ece..0531b9c 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -41,6 +41,7 @@ enum irq_alloc_type {
X86_IRQ_ALLOC_TYPE_DMAR,
X86_IRQ_ALLOC_TYPE_AMDVI,
X86_IRQ_ALLOC_TYPE_UV,
+ X86_IRQ_ALLOC_TYPE_DEV_MSI,
};
struct ioapic_alloc_info {
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 03/12] platform-msi: Provide default irq_chip:: Ack
From: Thomas Gleixner For the upcoming device MSI support it's required to have a default irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not need to care. Signed-off-by: Thomas Gleixner Signed-off-by: Megha Dey --- drivers/base/platform-msi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c index 2c1e2e0..9d9ccfc 100644 --- a/drivers/base/platform-msi.c +++ b/drivers/base/platform-msi.c @@ -101,6 +101,8 @@ static void platform_msi_update_chip_ops(struct msi_domain_info *info) chip->irq_mask = irq_chip_mask_parent; if (!chip->irq_unmask) chip->irq_unmask = irq_chip_unmask_parent; + if (!chip->irq_ack) + chip->irq_ack = irq_chip_ack_parent; if (!chip->irq_eoi) chip->irq_eoi = irq_chip_eoi_parent; if (!chip->irq_set_affinity) -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 04/12] genirq/proc: Take buslock on affinity write
From: Thomas Gleixner
Until now interrupt chips which support setting affinity are not locking
the associated bus lock for two reasons:
- All chips which support affinity setting do not use buslock because they
just can operated directly on the hardware.
- All chips which use buslock do not support affinity setting because
their interrupt chips are not capable. These chips are usually connected
over a bus like I2C, SPI etc. and have an interrupt output which is
conneted to CPU interrupt of some sort. So there is no way to set the
affinity on the chip itself.
Upcoming hardware which is PCIE based sports a non standard MSI(X) variant
which stores the MSI message in RAM which is associated to e.g. a device
queue. The device manages this RAM and writes have to be issued via command
queues or similar mechanisms which is obviously not possible from interrupt
disabled, raw spinlock held context.
The buslock mechanism of irq chips can be utilized to support that. The
affinity write to the chip writes to shadow state, marks it pending and the
irq chip's irq_bus_sync_unlock() callback handles the command queue and
wait for completion similar to the other chip operations on I2C or SPI
busses.
Change the locking in irq_set_affinity() to bus_lock/unlock to help with
that. There are a few other callers than the proc interface, but none of
them is affected by this change as none of them affects an irq chip with
bus lock support.
Signed-off-by: Thomas Gleixner
Signed-off-by: Megha Dey
---
kernel/irq/manage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index dec3f73..85ede4e 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -443,16 +443,16 @@ int irq_update_affinity_desc(unsigned int irq,
int __irq_set_affinity(unsigned int irq, const struct cpumask *mask, bool
force)
{
- struct irq_desc *desc = irq_to_desc(irq);
+ struct irq_desc *desc;
unsigned long flags;
int ret;
+ desc = irq_get_desc_buslock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
if (!desc)
return -EINVAL;
- raw_spin_lock_irqsave(&desc->lock, flags);
ret = irq_set_affinity_locked(irq_desc_get_irq_data(desc), mask, force);
- raw_spin_unlock_irqrestore(&desc->lock, flags);
+ irq_put_desc_busunlock(desc, flags);
return ret;
}
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path
On Wed, Feb 03, 2021 at 01:49:22PM +0100, Christoph Hellwig wrote: > On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote: > > Your comment makes sense but then that would require the cooperation > > of these vendors and the cloud providers to agree on something meaningful. > > I am also not sure whether the end result would be better than hardening > > this interface to catch corruption. There is already some validation in > > unmap path anyway. > > So what? If you guys want to provide a new capability you'll have to do > work. And designing a new protocol based around the fact that the > hardware/hypervisor is not trusted and a copy is always required makes > a lot of more sense than throwing in band aids all over the place. If you don't trust the hypervisor, what would this capability be in? I suppose you mean this would need to be in the the guest kernel and this protocol would depend on .. not-hypervisor and most certainly not the virtio or any SR-IOV device. That removes a lot of options. The one sensibile one (since folks will trust OEM vendors like Intel or AMD to provide the memory encryption so they will also trust the IOMMU - I hope?) - and they do have plans for that with their IOMMU frameworks which will remove the need for SWIOTLB (I hope). But that is not now, but in future. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 2/2] iommu: add Unisoc iommu basic driver
On 2/3/21 1:07 AM, Chunyan Zhang wrote: > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 192ef8f61310..99e7712f3903 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -408,4 +408,16 @@ config VIRTIO_IOMMU > > Say Y here if you intend to run this kernel as a guest. > > +config SPRD_IOMMU > + tristate "Unisoc IOMMU Support" > + depends on ARCH_SPRD || COMPILE_TEST > + select IOMMU_API > + help > + Support for IOMMU on Unisoc's SoCs, this iommu can be used by s/iommu/IOMMU/ please > + Unisoc's multimedia devices, such as display, Image codec(jpeg) > + and a few signal processors, including VSP(video), GSP(graphic), > + ISP(image), and CPP(camera pixel processor), etc. > + > + Say Y here if you want to use the multimedia devices listed above. -- ~Randy ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V2 3/3] Adding device_dma_parameters->offset_preserve_mask to NVMe driver.
>
> Please try with this extra patch:
>
I have tried with the extra patch and it still fails to boot.
I have attached dmesg output for the error:
-dmesg starts here-
[6.357755] XFS (nvme0n1p2): Mounting V5 Filesystem
[6.430092] XFS (nvme0n1p2): Torn write (CRC failure) detected at
log block 0x20d0. Truncating head block from 0x20e0.
[6.442828] XFS (nvme0n1p2): Starting recovery (logdev: internal)
[7.272456] XFS (nvme0n1p2): Ending recovery (logdev: internal)
[7.610250] systemd-journald[434]: Received SIGTERM from PID 1 (systemd).
...
[ 10.054121] systemd[755]:
/usr/lib/systemd/system-generators/systemd-rc-local-generator
terminated by signal ABRT.
[ 10.726122] audit: type=1400 audit(1612370261.090:4): avc: denied
{ search } for pid=783 comm="systemd-sysctl" name="crash"
dev="nvme0n1p2" ino=50789805
scontext=system_u:system_r:systemd_sysctl_t:s0
tcontext=system_u:object_r:kdump_crash_t:s0 tclass=dir permissive=0
[ 10.751764] audit: type=1400 audit(1612370261.090:5): avc: denied
{ search } for pid=783 comm="systemd-sysctl" name="crash"
dev="nvme0n1p2" ino=50789805
scontext=system_u:system_r:systemd_sysctl_t:s0
tcontext=system_u:object_r:kdump_crash_t:s0 tclass=dir permissive=0
[ 12.366607] xfs filesystem being remounted at / supports timestamps
until 2038 (0x7fff)
[ 12.376379] audit: type=1400 audit(1612370262.740:6): avc: denied
{ write } for pid=788 comm="systemd-remount" name="crash"
dev="nvme0n1p2" ino=50789805 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:kdump_crash_t:s0 tclass=dir permissive=0
[ 12.413155] systemd-journald[781]: Received request to flush
runtime journal from PID 1
[ 12.428917] audit: type=1400 audit(1612370262.793:7): avc: denied
{ write } for pid=815 comm="journalctl" name="crash" dev="nvme0n1p2"
ino=50789805 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:kdump_crash_t:s0 tclass=dir permissive=0
[ 12.453006] audit: type=1400 audit(1612370262.799:8): avc: denied
{ write } for pid=817 comm="systemd-random-" name="crash"
dev="nvme0n1p2" ino=50789805 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:kdump_crash_t:s0 tclass=dir permissive=0
[ 13.306030] plymouth[853]: segfault at 0 ip 7f2eabca8090 sp
7fffe94d8c08 error 6 in libc-2.28.so[7f2eabbcd000+1b9000]
[ 13.318772] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
[ 78.782418] sed[911]: segfault at 0 ip 7fc3540da090 sp
7ffdb4373ff8 error 6 in libc-2.28.so[7fc353fff000+1b9000]
[ 78.794007] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
--dmesg ends here---
--
Jianxiong Gao
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas
Hi Rob,
On Wed, Feb 3, 2021 at 4:55 PM Rob Herring wrote:
> On Wed, Feb 03, 2021 at 09:01:23AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote:
> > > Properties in if/then schemas weren't getting checked by the meta-schemas.
> > > Enabling meta-schema checks finds several errors.
> > >
> > > The use of an 'items' schema (as opposed to the list form) is wrong in
> > > some cases as it applies to all entries. 'contains' is the correct schema
> > > to use in the case of multiple entries.
> >
> > > Signed-off-by: Rob Herring
> >
> > Thanks for your patch!
> >
> > > --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> > > @@ -81,9 +81,8 @@ properties:
> > > if:
> > >properties:
> > > compatible:
> > > - items:
> > > -enum:
> > > - - renesas,usb2-phy-r7s9210
> > > + contains:
> > > +const: renesas,usb2-phy-r7s9210
> >
> > Single entry, so "contains" not needed?
>
> No, you are misunderstanding how these work. 'contains' means at least
> one entry in an array passes with the subschema. In this case,
> 'renesas,usb2-phy-r7s9210' must appear somewhere in the 'compatible'
> values. (Before, it said *every* entry must be
> 'renesas,usb2-phy-r7s9210'.) As there is a fallback compatible, we need
> 'contains'.
>
> > > --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> > > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> > > @@ -76,11 +76,10 @@ required:
> > > if:
> > >properties:
> > > compatible:
> > > - items:
> > > -enum:
> > > - - renesas,pfc-r8a73a4
> > > - - renesas,pfc-r8a7740
> > > - - renesas,pfc-sh73a0
> > > + enum:
> > > +- renesas,pfc-r8a73a4
> > > +- renesas,pfc-r8a7740
> > > +- renesas,pfc-sh73a0
> >
> > Missing "contains"?
>
> No. In this case, 'compatible' is always a single entry, so no
> 'contains' needed (but would work). If compatible is one of these 3
> strings, then the 'if' is true.
>
> The original way would actually work in this case (i.e. is valid
> json-schema), but we require 'items' to have a size (maxItems/minItems)
> in our meta-schema.
Thanks for the explanation!
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas
On Wed, Feb 03, 2021 at 09:01:23AM +0100, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote: > > Properties in if/then schemas weren't getting checked by the meta-schemas. > > Enabling meta-schema checks finds several errors. > > > > The use of an 'items' schema (as opposed to the list form) is wrong in > > some cases as it applies to all entries. 'contains' is the correct schema > > to use in the case of multiple entries. > > > Signed-off-by: Rob Herring > > Thanks for your patch! > > > --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml > > +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml > > @@ -81,9 +81,8 @@ properties: > > if: > >properties: > > compatible: > > - items: > > -enum: > > - - renesas,usb2-phy-r7s9210 > > + contains: > > +const: renesas,usb2-phy-r7s9210 > > Single entry, so "contains" not needed? No, you are misunderstanding how these work. 'contains' means at least one entry in an array passes with the subschema. In this case, 'renesas,usb2-phy-r7s9210' must appear somewhere in the 'compatible' values. (Before, it said *every* entry must be 'renesas,usb2-phy-r7s9210'.) As there is a fallback compatible, we need 'contains'. > > --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml > > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml > > @@ -76,11 +76,10 @@ required: > > if: > >properties: > > compatible: > > - items: > > -enum: > > - - renesas,pfc-r8a73a4 > > - - renesas,pfc-r8a7740 > > - - renesas,pfc-sh73a0 > > + enum: > > +- renesas,pfc-r8a73a4 > > +- renesas,pfc-r8a7740 > > +- renesas,pfc-sh73a0 > > Missing "contains"? No. In this case, 'compatible' is always a single entry, so no 'contains' needed (but would work). If compatible is one of these 3 strings, then the 'if' is true. The original way would actually work in this case (i.e. is valid json-schema), but we require 'items' to have a size (maxItems/minItems) in our meta-schema. Rob ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v6 16/16] iommu/hyperv: setup an IO-APIC IRQ remapping domain for root partition
Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
Hypervisor when Linux runs as the root partition. Implement an IRQ
domain to handle mapping and unmapping of IO-APIC interrupts.
Signed-off-by: Wei Liu
---
v6:
1. Simplify code due to changes in a previous patch.
---
arch/x86/hyperv/irqdomain.c | 25 +
arch/x86/include/asm/mshyperv.h | 4 +
drivers/iommu/hyperv-iommu.c| 177 +++-
3 files changed, 203 insertions(+), 3 deletions(-)
diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
index 117f17e8c88a..0cabc9aece38 100644
--- a/arch/x86/hyperv/irqdomain.c
+++ b/arch/x86/hyperv/irqdomain.c
@@ -360,3 +360,28 @@ struct irq_domain * __init hv_create_pci_msi_domain(void)
}
#endif /* CONFIG_PCI_MSI */
+
+int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry *entry)
+{
+ union hv_device_id device_id;
+
+ device_id.as_uint64 = 0;
+ device_id.device_type = HV_DEVICE_TYPE_IOAPIC;
+ device_id.ioapic.ioapic_id = (u8)ioapic_id;
+
+ return hv_unmap_interrupt(device_id.as_uint64, entry);
+}
+EXPORT_SYMBOL_GPL(hv_unmap_ioapic_interrupt);
+
+int hv_map_ioapic_interrupt(int ioapic_id, bool level, int cpu, int vector,
+ struct hv_interrupt_entry *entry)
+{
+ union hv_device_id device_id;
+
+ device_id.as_uint64 = 0;
+ device_id.device_type = HV_DEVICE_TYPE_IOAPIC;
+ device_id.ioapic.ioapic_id = (u8)ioapic_id;
+
+ return hv_map_interrupt(device_id, level, cpu, vector, entry);
+}
+EXPORT_SYMBOL_GPL(hv_map_ioapic_interrupt);
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ccc849e25d5e..345d7c6f8c37 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -263,6 +263,10 @@ static inline void hv_set_msi_entry_from_desc(union
hv_msi_entry *msi_entry,
struct irq_domain *hv_create_pci_msi_domain(void);
+int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int vector,
+ struct hv_interrupt_entry *entry);
+int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry *entry);
+
#else /* CONFIG_HYPERV */
static inline void hyperv_init(void) {}
static inline void hyperv_setup_mmu_ops(void) {}
diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
index 1d21a0b5f724..e285a220c913 100644
--- a/drivers/iommu/hyperv-iommu.c
+++ b/drivers/iommu/hyperv-iommu.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "irq_remapping.h"
@@ -115,30 +116,43 @@ static const struct irq_domain_ops hyperv_ir_domain_ops =
{
.free = hyperv_irq_remapping_free,
};
+static const struct irq_domain_ops hyperv_root_ir_domain_ops;
static int __init hyperv_prepare_irq_remapping(void)
{
struct fwnode_handle *fn;
int i;
+ const char *name;
+ const struct irq_domain_ops *ops;
if (!hypervisor_is_type(X86_HYPER_MS_HYPERV) ||
x86_init.hyper.msi_ext_dest_id() ||
!x2apic_supported())
return -ENODEV;
- fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
+ if (hv_root_partition) {
+ name = "HYPERV-ROOT-IR";
+ ops = &hyperv_root_ir_domain_ops;
+ } else {
+ name = "HYPERV-IR";
+ ops = &hyperv_ir_domain_ops;
+ }
+
+ fn = irq_domain_alloc_named_id_fwnode(name, 0);
if (!fn)
return -ENOMEM;
ioapic_ir_domain =
irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
- 0, IOAPIC_REMAPPING_ENTRY, fn,
- &hyperv_ir_domain_ops, NULL);
+ 0, IOAPIC_REMAPPING_ENTRY, fn, ops, NULL);
if (!ioapic_ir_domain) {
irq_domain_free_fwnode(fn);
return -ENOMEM;
}
+ if (hv_root_partition)
+ return 0; /* The rest is only relevant to guests */
+
/*
* Hyper-V doesn't provide irq remapping function for
* IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
@@ -166,4 +180,161 @@ struct irq_remap_ops hyperv_irq_remap_ops = {
.enable = hyperv_enable_irq_remapping,
};
+/* IRQ remapping domain when Linux runs as the root partition */
+struct hyperv_root_ir_data {
+ u8 ioapic_id;
+ bool is_level;
+ struct hv_interrupt_entry entry;
+};
+
+static void
+hyperv_root_ir_compose_msi_msg(struct irq_data *irq_data, struct msi_msg *msg)
+{
+ u64 status;
+ u32 vector;
+ struct irq_cfg *cfg;
+ int ioapic_id;
+ struct cpumask *affinity;
+ int cpu;
+ struct hv_interrupt_entry entry;
+ struct hyperv_root_ir_data *data = irq_data->chip_data;
+ struct IO_APIC_route_entry e;
+
+ cfg = irqd_cfg(irq_data);
+ affinity = irq_data_get_effective_affinity_mask(irq_data);
+ cpu = cpumask_firs
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
Hi Rob,
On Wed, 3 Feb 2021 at 05:55, Rob Herring wrote:
> diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> index 1f2ef408bb43..fe1e1c63ffe3 100644
> --- a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> @@ -46,7 +46,7 @@ examples:
> #include
>
> gpio: gpio@207800 {
> - compatible = "mstar,msc313e-gpio";
> + compatible = "mstar,msc313-gpio";
>#gpio-cells = <2>;
>reg = <0x207800 0x200>;
>gpio-controller;
This is correct. The compatible string dropped the e at some point and
I must have missed the example.
Thanks for the fix.
Reviewed-by: Daniel Palmer
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH][next] iommu/mediatek: Fix unsigned domid comparison with less than zero
From: Colin Ian King
Currently the check for domid < 0 is always false because domid
is unsigned. Fix this by making it signed.
Addresses-CoverityL ("Unsigned comparison against 0")
Fixes: ab1d5281a62b ("iommu/mediatek: Add iova reserved function")
Signed-off-by: Colin Ian King
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 0ad14a7604b1..823d719945b2 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -640,7 +640,7 @@ static void mtk_iommu_get_resv_regions(struct device *dev,
struct list_head *head)
{
struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
- unsigned int domid = mtk_iommu_get_domain_id(dev, data->plat_data), i;
+ int domid = mtk_iommu_get_domain_id(dev, data->plat_data), i;
const struct mtk_iommu_iova_region *resv, *curdom;
struct iommu_resv_region *region;
int prot = IOMMU_WRITE | IOMMU_READ;
--
2.29.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH V2 3/3] Adding device_dma_parameters->offset_preserve_mask to NVMe driver.
Please try with this extra patch:
---
>From 212764c3c15ce859e6f55d2146f450ea4ca6fdb9 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 3 Feb 2021 14:27:13 +0100
Subject: nvme-pci: fix 2nd PRP setup in nvme_setup_prp_simple
Use the dma address instead of the bio_vec offset for the arithmetics
to find the address for the 2nd PRP.
Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment
requests")
Reported-by: Jianxiong Gao
Signed-off-by: Christoph Hellwig
---
drivers/nvme/host/pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 30e45f7e0f750c..4ae51735d72f4a 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -808,8 +808,7 @@ static blk_status_t nvme_setup_prp_simple(struct nvme_dev
*dev,
struct bio_vec *bv)
{
struct nvme_iod *iod = blk_mq_rq_to_pdu(req);
- unsigned int offset = bv->bv_offset & (NVME_CTRL_PAGE_SIZE - 1);
- unsigned int first_prp_len = NVME_CTRL_PAGE_SIZE - offset;
+ dma_addr_t next_prp;
iod->first_dma = dma_map_bvec(dev->dev, bv, rq_dma_dir(req), 0);
if (dma_mapping_error(dev->dev, iod->first_dma))
@@ -817,8 +816,9 @@ static blk_status_t nvme_setup_prp_simple(struct nvme_dev
*dev,
iod->dma_len = bv->bv_len;
cmnd->dptr.prp1 = cpu_to_le64(iod->first_dma);
- if (bv->bv_len > first_prp_len)
- cmnd->dptr.prp2 = cpu_to_le64(iod->first_dma + first_prp_len);
+ next_prp = round_down(iod->first_dma + bv->bv_len, NVME_CTRL_PAGE_SIZE);
+ if (next_prp > iod->first_dma)
+ cmnd->dptr.prp2 = cpu_to_le64(next_prp);
return BLK_STS_OK;
}
--
2.29.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 2/2] iommu: add Unisoc iommu basic driver
Hi Chunyan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on robh/for-next v5.11-rc6 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Add-Unisoc-iommu-basic-driver/20210203-171459
base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/02726f17be90f0d6226117f44cef3497250e378f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Chunyan-Zhang/Add-Unisoc-iommu-basic-driver/20210203-171459
git checkout 02726f17be90f0d6226117f44cef3497250e378f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=nios2
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from ./arch/nios2/include/generated/asm/bug.h:1,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/current.h:5,
from ./arch/nios2/include/generated/asm/current.h:1,
from include/linux/mutex.h:14,
from include/linux/notifier.h:14,
from include/linux/clk.h:14,
from drivers/iommu/sprd-iommu.c:9:
drivers/iommu/sprd-iommu.c: In function 'sprd_iommu_iova_to_phys':
>> drivers/iommu/sprd-iommu.c:375:4: warning: format '%llx' expects argument of
>> type 'long long unsigned int', but argument 5 has type 'dma_addr_t' {aka
>> 'unsigned int'} [-Wformat=]
375 |"iova (0x%llx) exceeds the vpn range[0x%lx-0x%lx]\n",
|^~~~
376 |iova, start, end))
|
||
|dma_addr_t {aka unsigned int}
include/asm-generic/bug.h:89:48: note: in definition of macro '__WARN_printf'
89 | warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
|^~~
drivers/iommu/sprd-iommu.c:374:6: note: in expansion of macro 'WARN'
374 | if (WARN(iova < start || iova > end,
| ^~~~
drivers/iommu/sprd-iommu.c:375:16: note: format string is defined here
375 |"iova (0x%llx) exceeds the vpn range[0x%lx-0x%lx]\n",
| ~~~^
||
|long long unsigned int
| %x
drivers/iommu/sprd-iommu.c: At top level:
drivers/iommu/sprd-iommu.c:438:20: error: initialization of 'void (*)(struct
iommu_domain *, long unsigned int, size_t)' {aka 'void (*)(struct iommu_domain
*, long unsigned int, unsigned int)'} from incompatible pointer type 'void
(*)(struct iommu_domain *)' [-Werror=incompatible-pointer-types]
438 | .iotlb_sync_map = sprd_iommu_sync_map,
|^~~
drivers/iommu/sprd-iommu.c:438:20: note: (near initialization for
'sprd_iommu_ops.iotlb_sync_map')
cc1: some warnings being treated as errors
vim +375 drivers/iommu/sprd-iommu.c
364
365 static phys_addr_t sprd_iommu_iova_to_phys(struct iommu_domain *domain,
366 dma_addr_t iova)
367 {
368 struct sprd_iommu_domain *dom = to_sprd_domain(domain);
369 unsigned long flags;
370 phys_addr_t pa;
371 unsigned long start = domain->geometry.aperture_start;
372 unsigned long end = domain->geometry.aperture_end;
373
374 if (WARN(iova < start || iova > end,
> 375 "iova (0x%llx) exceeds the vpn range[0x%lx-0x%lx]\n",
376 iova, start, end))
377 return 0;
378
379 spin_lock_irqsave(&dom->pgtlock, flags);
380 pa = *(dom->pgt_va + ((iova - start) >> SPRD_IOMMU_PAGE_SHIFT));
381 pa = (pa << SPRD_IOMMU_PAGE_SHIFT) + ((iova - start) &
(SPRD_IOMMU_PAGE_SIZE - 1));
382 spin_unlock_irqrestore(&dom->pgtlock, flags);
383
384 return pa;
385 }
386
---
0-DAY CI Kernel Test Service,
Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path
On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote: > Your comment makes sense but then that would require the cooperation > of these vendors and the cloud providers to agree on something meaningful. > I am also not sure whether the end result would be better than hardening > this interface to catch corruption. There is already some validation in > unmap path anyway. So what? If you guys want to provide a new capability you'll have to do work. And designing a new protocol based around the fact that the hardware/hypervisor is not trusted and a copy is always required makes a lot of more sense than throwing in band aids all over the place. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 16/16] iommu/hyperv: setup an IO-APIC IRQ remapping domain for root partition
On Wed, Jan 27, 2021 at 05:47:08AM +, Michael Kelley wrote:
> From: Wei Liu Sent: Wednesday, January 20, 2021 4:01 AM
> >
> > Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
> > Hypervisor when Linux runs as the root partition. Implement an IRQ
> > domain to handle mapping and unmapping of IO-APIC interrupts.
> >
> > Signed-off-by: Wei Liu
> > ---
> > arch/x86/hyperv/irqdomain.c | 54 ++
> > arch/x86/include/asm/mshyperv.h | 4 +
> > drivers/iommu/hyperv-iommu.c| 179 +++-
> > 3 files changed, 233 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
> > index 19637cd60231..8e2b4e478b70 100644
> > --- a/arch/x86/hyperv/irqdomain.c
> > +++ b/arch/x86/hyperv/irqdomain.c
> > @@ -330,3 +330,57 @@ struct irq_domain * __init
> > hv_create_pci_msi_domain(void)
> > }
> >
> > #endif /* CONFIG_PCI_MSI */
> > +
> > +int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry
> > *entry)
> > +{
> > + union hv_device_id device_id;
> > +
> > + device_id.as_uint64 = 0;
> > + device_id.device_type = HV_DEVICE_TYPE_IOAPIC;
> > + device_id.ioapic.ioapic_id = (u8)ioapic_id;
> > +
> > + return hv_unmap_interrupt(device_id.as_uint64, entry) &
> > HV_HYPERCALL_RESULT_MASK;
>
> The masking is already done in hv_unmap_interrupt.
Fixed.
>
> > +}
> > +EXPORT_SYMBOL_GPL(hv_unmap_ioapic_interrupt);
> > +
> > +int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int
> > vector,
> > + struct hv_interrupt_entry *entry)
> > +{
> > + unsigned long flags;
> > + struct hv_input_map_device_interrupt *input;
> > + struct hv_output_map_device_interrupt *output;
> > + union hv_device_id device_id;
> > + struct hv_device_interrupt_descriptor *intr_desc;
> > + u16 status;
> > +
> > + device_id.as_uint64 = 0;
> > + device_id.device_type = HV_DEVICE_TYPE_IOAPIC;
> > + device_id.ioapic.ioapic_id = (u8)ioapic_id;
> > +
> > + local_irq_save(flags);
> > + input = *this_cpu_ptr(hyperv_pcpu_input_arg);
> > + output = *this_cpu_ptr(hyperv_pcpu_output_arg);
> > + memset(input, 0, sizeof(*input));
> > + intr_desc = &input->interrupt_descriptor;
> > + input->partition_id = hv_current_partition_id;
> > + input->device_id = device_id.as_uint64;
> > + intr_desc->interrupt_type = HV_X64_INTERRUPT_TYPE_FIXED;
> > + intr_desc->target.vector = vector;
> > + intr_desc->vector_count = 1;
> > +
> > + if (level)
> > + intr_desc->trigger_mode = HV_INTERRUPT_TRIGGER_MODE_LEVEL;
> > + else
> > + intr_desc->trigger_mode = HV_INTERRUPT_TRIGGER_MODE_EDGE;
> > +
> > + __set_bit(vcpu, (unsigned long *)&intr_desc->target.vp_mask);
> > +
> > + status = hv_do_rep_hypercall(HVCALL_MAP_DEVICE_INTERRUPT, 0, 0, input,
> > output) &
> > +HV_HYPERCALL_RESULT_MASK;
> > + local_irq_restore(flags);
> > +
> > + *entry = output->interrupt_entry;
> > +
> > + return status;
>
> As a cross-check, I was comparing this code against hv_map_msi_interrupt().
> They are
> mostly parallel, though some of the assignments are done in a different
> order. It's a nit,
> but making them as parallel as possible would be nice. :-)
>
Indeed. I will see about factoring out a function.
> Same 64 vCPU comment applies here as well.
>
This is changed to use vpset instead. Took me a bit of time to get it
working because document is a bit lacking.
>
> > +}
> > +EXPORT_SYMBOL_GPL(hv_map_ioapic_interrupt);
> > diff --git a/arch/x86/include/asm/mshyperv.h
> > b/arch/x86/include/asm/mshyperv.h
> > index ccc849e25d5e..345d7c6f8c37 100644
> > --- a/arch/x86/include/asm/mshyperv.h
> > +++ b/arch/x86/include/asm/mshyperv.h
> > @@ -263,6 +263,10 @@ static inline void hv_set_msi_entry_from_desc(union
> > hv_msi_entry *msi_entry,
> >
> > struct irq_domain *hv_create_pci_msi_domain(void);
> >
> > +int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int
> > vector,
> > + struct hv_interrupt_entry *entry);
> > +int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry
> > *entry);
> > +
> > #else /* CONFIG_HYPERV */
> > static inline void hyperv_init(void) {}
> > static inline void hyperv_setup_mmu_ops(void) {}
> > diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> > index b7db6024e65c..6d35e4c303c6 100644
> > --- a/drivers/iommu/hyperv-iommu.c
> > +++ b/drivers/iommu/hyperv-iommu.c
> > @@ -116,30 +116,43 @@ static const struct irq_domain_ops
> > hyperv_ir_domain_ops = {
> > .free = hyperv_irq_remapping_free,
> > };
> >
> > +static const struct irq_domain_ops hyperv_root_ir_domain_ops;
> > static int __init hyperv_prepare_irq_remapping(void)
> > {
> > struct fwnode_handle *fn;
> > int i;
> > + const char *name;
> > + const struct irq_domain_ops *ops;
> >
> > if (!hypervisor_is_type(X86_HYPER_MS_HYPERV) ||
> > x86_init.hyper.msi_ext_dest_id() ||
Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas
On Tue, 2021-02-02 at 14:55 -0600, Rob Herring wrote: > Properties in if/then schemas weren't getting checked by the meta-schemas. > Enabling meta-schema checks finds several errors. > > The use of an 'items' schema (as opposed to the list form) is wrong in > some cases as it applies to all entries. 'contains' is the correct schema > to use in the case of multiple entries. > > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Eric Anholt > Cc: Nicolas Saenz Julienne > Cc: Florian Fainelli > Cc: Ray Jui > Cc: Scott Branden > Cc: Pavel Machek > Cc: Ulf Hansson > Cc: Kishon Vijay Abraham I > Cc: Vinod Koul > Cc: Geert Uytterhoeven > Cc: Linus Walleij > Cc: Daniel Lezcano > Cc: linux-cry...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-l...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Signed-off-by: Rob Herring > --- Reviewed-by: Nicolas Saenz Julienne signature.asc Description: This is a digitally signed message part ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas
On 02-02-21, 14:55, Rob Herring wrote: > Properties in if/then schemas weren't getting checked by the meta-schemas. > Enabling meta-schema checks finds several errors. > > The use of an 'items' schema (as opposed to the list form) is wrong in > some cases as it applies to all entries. 'contains' is the correct schema > to use in the case of multiple entries. > > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Eric Anholt > Cc: Nicolas Saenz Julienne > Cc: Florian Fainelli > Cc: Ray Jui > Cc: Scott Branden > Cc: Pavel Machek > Cc: Ulf Hansson > Cc: Kishon Vijay Abraham I > Cc: Vinod Koul > Cc: Geert Uytterhoeven > Cc: Linus Walleij > Cc: Daniel Lezcano > Cc: linux-cry...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-l...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/crypto/allwinner,sun8i-ce.yaml | 3 +-- > .../devicetree/bindings/display/brcm,bcm2835-hvs.yaml| 2 +- > Documentation/devicetree/bindings/leds/ti,tca6507.yaml | 1 + > Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 2 +- > Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml | 3 +-- > .../devicetree/bindings/phy/renesas,usb2-phy.yaml| 5 ++--- For phy: Acked-By: Vinod Koul -- ~Vinod ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/3] iommu/vt-d: Add support for ACPI/SATC table
Add the change log. Sorry for the quick sent. On 2021/2/3 17:33, Lu Baolu wrote: The Intel VT-d specification v3.2 comes with a new ACPI SATC (SoC- Integrated Address Translation Cache) reporting structure. The SoC integrated device enumerated in this table has a functional requirement to enable its ATC (Address Translation Cache) via the ATS capability for device operation. This patch set adds the code to parse the SATC table, enumerates the devices in it and satisfies the ATS requirement for them. Please help to review. I will queue it in VT-d update for v5.12 if no objection. Change log: v1->v2: - Rephrase some words in the cover letter, commit message and code comments. - Refactored a code style to make it look nicer. Best regards, baolu Yian Chen (3): iommu/vt-d: Add new enum value and structure for SATC iommu/vt-d: Parse SATC reporting structure iommu/vt-d: Apply SATC policy drivers/iommu/intel/dmar.c | 8 ++ drivers/iommu/intel/iommu.c | 162 +++- include/acpi/actbl1.h | 11 ++- include/linux/dmar.h| 2 + 4 files changed, 178 insertions(+), 5 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/3] iommu/vt-d: Add support for ACPI/SATC table
The Intel VT-d specification v3.2 comes with a new ACPI SATC (SoC- Integrated Address Translation Cache) reporting structure. The SoC integrated device enumerated in this table has a functional requirement to enable its ATC (Address Translation Cache) via the ATS capability for device operation. This patch set adds the code to parse the SATC table, enumerates the devices in it and satisfies the ATS requirement for them. Please help to review. I will queue it in VT-d update for v5.12 if no objection. Yian Chen (3): iommu/vt-d: Add new enum value and structure for SATC iommu/vt-d: Parse SATC reporting structure iommu/vt-d: Apply SATC policy drivers/iommu/intel/dmar.c | 8 ++ drivers/iommu/intel/iommu.c | 162 +++- include/acpi/actbl1.h | 11 ++- include/linux/dmar.h| 2 + 4 files changed, 178 insertions(+), 5 deletions(-) -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/3] iommu/vt-d: Parse SATC reporting structure
From: Yian Chen
Software should parse every SATC table and all devices in the tables
reported by the BIOS and keep the information in kernel list for further
reference.
Signed-off-by: Yian Chen
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/dmar.c | 8
drivers/iommu/intel/iommu.c | 89 +
include/linux/dmar.h| 2 +
3 files changed, 99 insertions(+)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 980e8ae090af..d5c51b5c20af 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -526,6 +526,7 @@ dmar_table_print_dmar_entry(struct acpi_dmar_header *header)
struct acpi_dmar_reserved_memory *rmrr;
struct acpi_dmar_atsr *atsr;
struct acpi_dmar_rhsa *rhsa;
+ struct acpi_dmar_satc *satc;
switch (header->type) {
case ACPI_DMAR_TYPE_HARDWARE_UNIT:
@@ -555,6 +556,10 @@ dmar_table_print_dmar_entry(struct acpi_dmar_header
*header)
/* We don't print this here because we need to sanity-check
it first. So print it in dmar_parse_one_andd() instead. */
break;
+ case ACPI_DMAR_TYPE_SATC:
+ satc = container_of(header, struct acpi_dmar_satc, header);
+ pr_info("SATC flags: 0x%x\n", satc->flags);
+ break;
}
}
@@ -642,6 +647,7 @@ parse_dmar_table(void)
.cb[ACPI_DMAR_TYPE_ROOT_ATS] = &dmar_parse_one_atsr,
.cb[ACPI_DMAR_TYPE_HARDWARE_AFFINITY] = &dmar_parse_one_rhsa,
.cb[ACPI_DMAR_TYPE_NAMESPACE] = &dmar_parse_one_andd,
+ .cb[ACPI_DMAR_TYPE_SATC] = &dmar_parse_one_satc,
};
/*
@@ -2077,6 +2083,7 @@ static guid_t dmar_hp_guid =
#defineDMAR_DSM_FUNC_DRHD 1
#defineDMAR_DSM_FUNC_ATSR 2
#defineDMAR_DSM_FUNC_RHSA 3
+#defineDMAR_DSM_FUNC_SATC 4
static inline bool dmar_detect_dsm(acpi_handle handle, int func)
{
@@ -2094,6 +2101,7 @@ static int dmar_walk_dsm_resource(acpi_handle handle, int
func,
[DMAR_DSM_FUNC_DRHD] = ACPI_DMAR_TYPE_HARDWARE_UNIT,
[DMAR_DSM_FUNC_ATSR] = ACPI_DMAR_TYPE_ROOT_ATS,
[DMAR_DSM_FUNC_RHSA] = ACPI_DMAR_TYPE_HARDWARE_AFFINITY,
+ [DMAR_DSM_FUNC_SATC] = ACPI_DMAR_TYPE_SATC,
};
if (!dmar_detect_dsm(handle, func))
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ecbd05d8a1fc..ee0932307d64 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -316,8 +316,18 @@ struct dmar_atsr_unit {
u8 include_all:1; /* include all ports */
};
+struct dmar_satc_unit {
+ struct list_head list; /* list of SATC units */
+ struct acpi_dmar_header *hdr; /* ACPI header */
+ struct dmar_dev_scope *devices; /* target devices */
+ struct intel_iommu *iommu; /* the corresponding iommu */
+ int devices_cnt;/* target device count */
+ u8 atc_required:1; /* ATS is required */
+};
+
static LIST_HEAD(dmar_atsr_units);
static LIST_HEAD(dmar_rmrr_units);
+static LIST_HEAD(dmar_satc_units);
#define for_each_rmrr_units(rmrr) \
list_for_each_entry(rmrr, &dmar_rmrr_units, list)
@@ -3716,6 +3726,57 @@ int dmar_check_one_atsr(struct acpi_dmar_header *hdr,
void *arg)
return 0;
}
+static struct dmar_satc_unit *dmar_find_satc(struct acpi_dmar_satc *satc)
+{
+ struct dmar_satc_unit *satcu;
+ struct acpi_dmar_satc *tmp;
+
+ list_for_each_entry_rcu(satcu, &dmar_satc_units, list,
+ dmar_rcu_check()) {
+ tmp = (struct acpi_dmar_satc *)satcu->hdr;
+ if (satc->segment != tmp->segment)
+ continue;
+ if (satc->header.length != tmp->header.length)
+ continue;
+ if (memcmp(satc, tmp, satc->header.length) == 0)
+ return satcu;
+ }
+
+ return NULL;
+}
+
+int dmar_parse_one_satc(struct acpi_dmar_header *hdr, void *arg)
+{
+ struct acpi_dmar_satc *satc;
+ struct dmar_satc_unit *satcu;
+
+ if (system_state >= SYSTEM_RUNNING && !intel_iommu_enabled)
+ return 0;
+
+ satc = container_of(hdr, struct acpi_dmar_satc, header);
+ satcu = dmar_find_satc(satc);
+ if (satcu)
+ return 0;
+
+ satcu = kzalloc(sizeof(*satcu) + hdr->length, GFP_KERNEL);
+ if (!satcu)
+ return -ENOMEM;
+
+ satcu->hdr = (void *)(satcu + 1);
+ memcpy(satcu->hdr, hdr, hdr->length);
+ satcu->atc_required = satc->flags & 0x1;
+ satcu->devices = dmar_alloc_dev_scope((void *)(satc + 1),
+ (void *)satc +
satc->header.length,
+ &satcu->devices_cnt);
+
[PATCH v2 3/3] iommu/vt-d: Apply SATC policy
From: Yian Chen
Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
table structure. SATC table lists a set of SoC integrated devices that
require ATC to work (VT-d specification v3.2, section 8.8). Furthermore,
the new version of IOMMU supports SoC device ATS in both its Scalable mode
and legacy mode.
When IOMMU is working in scalable mode, software must enable device ATS
support. On the other hand, when IOMMU is in legacy mode for whatever
reason, the hardware managed ATS will automatically take effect and the
SATC required devices can work transparently to the software. As the
result, software shouldn't enable ATS on that device, otherwise duplicate
device TLB invalidations will occur.
Signed-off-by: Yian Chen
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 73 +++--
1 file changed, 69 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee0932307d64..3e30c340e6a9 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -872,6 +872,60 @@ static bool iommu_is_dummy(struct intel_iommu *iommu,
struct device *dev)
return false;
}
+static bool iommu_support_ats(struct intel_iommu *iommu)
+{
+ return ecap_dev_iotlb_support(iommu->ecap);
+}
+
+static bool device_support_ats(struct pci_dev *dev)
+{
+ return pci_ats_supported(dev) && dmar_find_matched_atsr_unit(dev);
+}
+
+static int segment_atc_required(u16 segment)
+{
+ struct acpi_dmar_satc *satc;
+ struct dmar_satc_unit *satcu;
+ int ret = 1;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(satcu, &dmar_satc_units, list) {
+ satc = container_of(satcu->hdr, struct acpi_dmar_satc, header);
+ if (satcu->atc_required && satcu->devices_cnt &&
+ satc->segment == segment)
+ goto out;
+ }
+ ret = 0;
+out:
+ rcu_read_unlock();
+ return ret;
+}
+
+static int device_atc_required(struct pci_dev *dev)
+{
+ struct dmar_satc_unit *satcu;
+ struct acpi_dmar_satc *satc;
+ struct device *tmp;
+ int i, ret = 1;
+
+ dev = pci_physfn(dev);
+ rcu_read_lock();
+ list_for_each_entry_rcu(satcu, &dmar_satc_units, list) {
+ satc = container_of(satcu->hdr, struct acpi_dmar_satc, header);
+ if (!satcu->atc_required ||
+ satc->segment != pci_domain_nr(dev->bus))
+ continue;
+
+ for_each_dev_scope(satcu->devices, satcu->devices_cnt, i, tmp)
+ if (to_pci_dev(tmp) == dev)
+ goto out;
+ }
+ ret = 0;
+out:
+ rcu_read_unlock();
+ return ret;
+}
+
struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devfn)
{
struct dmar_drhd_unit *drhd = NULL;
@@ -2555,10 +2609,16 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
if (dev && dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(info->dev);
- if (ecap_dev_iotlb_support(iommu->ecap) &&
- pci_ats_supported(pdev) &&
- dmar_find_matched_atsr_unit(pdev))
- info->ats_supported = 1;
+ /*
+* Support ATS by default if it's supported by both IOMMU and
+* client sides, except that the device's ATS is required by
+* ACPI/SATC but the IOMMU scalable mode is disabled. In that
+* case the hardware managed ATS will be automatically used.
+*/
+ if (iommu_support_ats(iommu) && device_support_ats(pdev)) {
+ if (!device_atc_required(pdev) || sm_supported(iommu))
+ info->ats_supported = 1;
+ }
if (sm_supported(iommu)) {
if (pasid_supported(iommu)) {
@@ -3155,6 +3215,11 @@ static int __init init_dmars(void)
* endfor
*/
for_each_drhd_unit(drhd) {
+ if (pci_ats_disabled() && segment_atc_required(drhd->segment)) {
+ pr_warn("Scalable mode disabled -- Use hardware managed
ATS because PCIe ATS is disabled but some devices in PCIe segment 0x%x require
it.",
+ drhd->segment);
+ intel_iommu_sm = 0;
+ }
/*
* lock not needed as this is only incremented in the single
* threaded kernel __init code path all other access are read
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/3] iommu/vt-d: Add new enum value and structure for SATC
From: Yian Chen
Starting from Intel Platform VT-d v3.2, BIOS may provide new remapping
structure SATC for SOC integrated devices, according to section 8.8 of
Intel VT-d architecture specification v3.2. The SATC structure reports
a list of the devices that require ATS for normal device operation. It
is a functional requirement that these devices will not work without OS
enabling ATS capability.
This patch introduces the new enum value and structure to represent the
remapping information. Kernel should parse the information from the
reporting structure and enable ATC for the devices as needed.
Signed-off-by: Yian Chen
Signed-off-by: Lu Baolu
---
include/acpi/actbl1.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 43549547ed3e..c38e08cf1b9e 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -514,7 +514,8 @@ enum acpi_dmar_type {
ACPI_DMAR_TYPE_ROOT_ATS = 2,
ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,
ACPI_DMAR_TYPE_NAMESPACE = 4,
- ACPI_DMAR_TYPE_RESERVED = 5 /* 5 and greater are reserved */
+ ACPI_DMAR_TYPE_SATC = 5,
+ ACPI_DMAR_TYPE_RESERVED = 6 /* 6 and greater are reserved */
};
/* DMAR Device Scope structure */
@@ -607,6 +608,14 @@ struct acpi_dmar_andd {
char device_name[1];
};
+/* 5: SOC Integrated Address Translation Cache Reporting Structure */
+
+struct acpi_dmar_satc {
+ struct acpi_dmar_header header;
+ u8 flags;
+ u8 reserved;
+ u16 segment;
+};
/***
*
* DRTM - Dynamic Root of Trust for Measurement table
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote: > Running 'dt-validate -m' will flag any compatible strings missing a schema. > Fix all the errors found in DT binding examples. Most of these are just > typos. > > Cc: Stephen Boyd > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Linus Walleij > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Daniel Palmer > Cc: Bartosz Golaszewski > Cc: Avi Fishman > Cc: Tomer Maimon > Cc: Tali Perry > Cc: Joerg Roedel > Cc: Will Deacon > Cc: Andrew Jeffery > Cc: Joel Stanley > Cc: Wim Van Sebroeck > Cc: Guenter Roeck > Cc: Yoshihiro Shimoda > Cc: Vincent Cheng > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-watch...@vger.kernel.org > Signed-off-by: Rob Herring Ooops. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] iommu/vt-d: Add support for ACPI/SATC table
Hi Christoph, On 2021/2/3 16:41, Christoph Hellwig wrote: On Tue, Feb 02, 2021 at 12:40:54PM +0800, Lu Baolu wrote: Intel platform VT-d (v3.2) comes with a new type of DMAR subtable SATC. The SATC table includes a list of SoC integrated devices that require SATC. OS software can use this table to enable ATS only for the devices in the list. This all sounds like gibberish. Please expand and if necessary explain acronyms when first used in each commit log / cover letter. I will rephrase the words. Best regards, baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 2/2] iommu: add Unisoc iommu basic driver
From: Chunyan Zhang
This iommu module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
Signed-off-by: Chunyan Zhang
---
drivers/iommu/Kconfig | 12 +
drivers/iommu/Makefile | 1 +
drivers/iommu/sprd-iommu.c | 600 +
3 files changed, 613 insertions(+)
create mode 100644 drivers/iommu/sprd-iommu.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 192ef8f61310..99e7712f3903 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -408,4 +408,16 @@ config VIRTIO_IOMMU
Say Y here if you intend to run this kernel as a guest.
+config SPRD_IOMMU
+ tristate "Unisoc IOMMU Support"
+ depends on ARCH_SPRD || COMPILE_TEST
+ select IOMMU_API
+ help
+ Support for IOMMU on Unisoc's SoCs, this iommu can be used by
+ Unisoc's multimedia devices, such as display, Image codec(jpeg)
+ and a few signal processors, including VSP(video), GSP(graphic),
+ ISP(image), and CPP(camera pixel processor), etc.
+
+ Say Y here if you want to use the multimedia devices listed above.
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 61bd30cd8369..5925b6af2123 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
obj-$(CONFIG_IOMMU_SVA_LIB) += iommu-sva-lib.o
+obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
new file mode 100644
index ..6b3c36785c7c
--- /dev/null
+++ b/drivers/iommu/sprd-iommu.c
@@ -0,0 +1,600 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Unisoc IOMMU driver
+ *
+ * Copyright (C) 2020 Unisoc, Inc.
+ * Author: Chunyan Zhang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SPRD_IOMMU_PAGE_SHIFT 12
+#define SPRD_IOMMU_PAGE_SIZE SZ_4K
+
+#define SPRD_EX_CFG0x0
+#define SPRD_IOMMU_VAOR_BYPASS BIT(4)
+#define SPRD_IOMMU_GATE_EN BIT(1)
+#define SPRD_IOMMU_EN BIT(0)
+#define SPRD_EX_UPDATE 0x4
+#define SPRD_EX_FIRST_VPN 0x8
+#define SPRD_EX_VPN_RANGE 0xc
+#define SPRD_EX_FIRST_PPN 0x10
+#define SPRD_EX_DEFAULT_PPN0x14
+
+#define SPRD_IOMMU_VERSION 0x0
+#define SPRD_VERSION_MASK GENMASK(15, 8)
+#define SPRD_VERSION_SHIFT 0x8
+#define SPRD_VAU_CFG 0x4
+#define SPRD_VAU_UPDATE0x8
+#define SPRD_VAU_AUTH_CFG 0xc
+#define SPRD_VAU_FIRST_PPN 0x10
+#define SPRD_VAU_DEFAULT_PPN_RD0x14
+#define SPRD_VAU_DEFAULT_PPN_WR0x18
+#define SPRD_VAU_FIRST_VPN 0x1c
+#define SPRD_VAU_VPN_RANGE 0x20
+
+enum sprd_iommu_version {
+ SPRD_IOMMU_EX,
+ SPRD_IOMMU_VAU,
+};
+
+/*
+ * struct sprd_iommu_device - high-level sprd iommu device representation,
+ * including hardware information and configuration, also driver data, etc
+ *
+ * @ver: sprd iommu device version
+ * @prot_page_va: protect page base virtual address
+ * @prot_page_pa: protect page base physical address, data would be
+ * written to here while translation fault
+ * @base: mapped base address for accessing registers
+ * @reg_offset: some IOMMU shares the same range of registers with the
multimedia
+ * device which use it, this represents the iommu register offset
+ * @dev: pointer to basic device structure
+ * @iommu: IOMMU core representation
+ * @group: IOMMU group
+ * @eb: gate clock which controls iommu access
+ */
+struct sprd_iommu_device {
+ enum sprd_iommu_version ver;
+ u32 *prot_page_va;
+ dma_addr_t prot_page_pa;
+ struct regmap *base;
+ unsigned intreg_offset;
+ struct device *dev;
+ struct iommu_device iommu;
+ struct iommu_group *group;
+ struct clk *eb;
+};
+
+struct sprd_iommu_domain {
+ spinlock_t pgtlock; /* lock for page table */
+ struct iommu_domain domain;
+ u32 *pgt_va; /* page table virtual address base */
+ dma_addr_t pgt_pa; /* page table physical address base */
+ struct sprd_iommu_device*sdev;
+};
+
+static const struct iommu_ops sprd_iommu_ops;
+
+static struct sprd_iommu_domain *to_sprd_domain(struct iommu_domain *dom)
+{
+ return container_of(dom, struct sprd_iommu_domain, domain);
+}
+
+static inline void
+sprd_iommu_write(struct sprd_iommu_device *sdev, unsigned int reg, u32 val)
+{
+ regmap_write(sdev->base, sdev->reg_offset + reg, val);
+}
+
+static inline u32
+sprd_iommu_read(struct sprd_iommu_de
[PATCH v3 1/2] dt-bindings: iommu: add bindings for sprd iommu
From: Chunyan Zhang
This iommu module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
Signed-off-by: Chunyan Zhang
---
.../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
new file mode 100644
index ..4fc99e81fa66
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2020 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc IOMMU and Multi-media MMU
+
+maintainers:
+ - Chunyan Zhang
+
+properties:
+ compatible:
+enum:
+ - sprd,iommu-v1
+
+ "#iommu-cells":
+const: 0
+description:
+ Unisoc IOMMUs are all single-master IOMMU devices, therefore no
+ additional information needs to associate with its master device.
+ Please refer to the generic bindings document for more details,
+ Documentation/devicetree/bindings/iommu/iommu.txt
+
+ reg:
+maxItems: 1
+description:
+ Not required if 'sprd,iommu-regs' is defined.
+
+ clocks:
+description:
+ Reference to a gate clock phandle, since access to some of IOMMUs are
+ controlled by gate clock, but this is not required.
+
+ sprd,iommu-regs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+ Reference to a syscon phandle plus 1 cell, the syscon defines the
+ register range used by the iommu and the media device, the cell
+ defines the offset for iommu registers. Since iommu module shares
+ the same register range with the media device which uses it.
+
+required:
+ - compatible
+ - "#iommu-cells"
+
+oneOf:
+ - required:
+ - reg
+ - required:
+ - sprd,iommu-regs
+
+additionalProperties: false
+
+examples:
+ - |
+iommu_disp: iommu-disp {
+ compatible = "sprd,iommu-v1";
+ sprd,iommu-regs = <&dpu_regs 0x800>;
+ #iommu-cells = <0>;
+};
+
+ - |
+iommu_jpg: iommu-jpg {
+ compatible = "sprd,iommu-v1";
+ sprd,iommu-regs = <&jpg_regs 0x300>;
+ #iommu-cells = <0>;
+ clocks = <&mm_gate 1>;
+};
+
+...
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 0/2] Add Unisoc iommu basic driver
From: Chunyan Zhang Changes since v2: * Added a WARN and return 0 if an invalid iova was passed to sprd_iommu_iova_to_phys(); * Changed the name of sprd_iommu_write(); * Revised CONFIG_SPRD_IOMMU help graph in Kconfig. * Revised comments for the struct sprd_iommu_device; * Converted to use "GPL" instread of "GPL v2", they are same as license-rules.rst shows. Changes since v1: * Fixed compile errors reported by kernel test robot . * Changed to use syscon to get mapped registers for iommu and media devices to avoid double map issue. * Addressed Robin's comments: - Added including offset in the returned physical address if the input virtual address isn't page-aligned; - Added platform_device_put() after calling of_find_device_by_node(); - Removed iommu register offset from driver, it will be defined as the cell of DT reference to syscon phandle; - Removed multi compatible strings which are not needed; - Added comments for the function sprd_iommu_clk_enable(); - Added clocks property in bindings; - Set device_driver.suppress_bind_attrs to disable unbind the devices via sysfs; - A few trivial fixes. Changes since RFC v2: * Addressed Robin's comments: - Add COMPILE_TEST support; - Use DMA allocator for PTE; - Revised to avoid resource leak issue; - Added ->iotlb_sync implemented; - Moved iommu group allocation to probe; - Changed some function names to make them sprd specific; * Added support for more iommu instance; Changes since RFC v1: * Rebased on v5.11-rc1; * Changed sprd-iommu to tristate; * Removed check for args_count of iommu OF node, since there's no args for sprd-iommu device node; * Added another IP version (i.e. vau); * Removed unnecessary configs selection from CONFIG_SPRD_IOMMU; * Changed to get zeroed pages. Chunyan Zhang (2): dt-bindings: iommu: add bindings for sprd iommu iommu: add Unisoc iommu basic driver .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++ drivers/iommu/Kconfig | 12 + drivers/iommu/Makefile| 1 + drivers/iommu/sprd-iommu.c| 600 ++ 4 files changed, 685 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml create mode 100644 drivers/iommu/sprd-iommu.c -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [EXTERNAL] Re: Question regarding VIOT proposal
On Tue, Feb 02, 2021 at 01:27:13PM -0700, Al Stone wrote: > On 02 Feb 2021 10:17, Jean-Philippe Brucker wrote: > > Hi Al, > > > > On Fri, Dec 04, 2020 at 01:18:25PM -0700, Al Stone wrote: > > > > I updated the doc: https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf > > > > You can incorporate it into the ASWG proposal. > > > > Changes since v8: > > > > * One typo (s/programing/programming/) > > > > * Modified the PCI Range node to include a segment range. > > > > > > > > I also updated the Linux and QEMU implementations on branch > > > > virtio-iommu/devel in https://jpbrucker.net/git/linux/ and > > > > https://jpbrucker.net/git/qemu/ > > > > > > > > Thanks again for helping with this > > > > > > > > Jean > > > > > > Perfect. Thanks. I'll update the ASWG info right away. > > > > Has there been any more feedback on the VIOT specification? I'm wondering > > when we can start upstreaming support for it. > > > > Thanks, > > Jean > > Ah, sorry, Jean. I meant to get back to you sooner. My apologies. > > The latest version that resulted from the discussion with Yinghan of > Microsoft is the one in front the ASWG; I think if you upstream that > version, it should be identical to the spec when it is next published > (post ACPI 6.4). > > The process is: (1) propose the change, (2) review it in committee, > (3) give people more time to think about it, then (4) have a finale > vote. We've been iterating over (1), (2) and (3). Since there was > no new discussion at the last meeting, we should have the final vote > on this (4) in the next meeting. I had hoped we could do that last > week but the meeting was canceled at the last minute. I hope to have > the final vote this Thursday and will let you know as soon as it has > been decided. > > My apologies for the delays; getting things done by committee always > takes a bazillion times longer than one would think. No worries, thanks a lot for the update! Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] iommu/vt-d: Add support for ACPI/SATC table
On Tue, Feb 02, 2021 at 12:40:54PM +0800, Lu Baolu wrote: > Intel platform VT-d (v3.2) comes with a new type of DMAR subtable > SATC. The SATC table includes a list of SoC integrated devices > that require SATC. OS software can use this table to enable ATS > only for the devices in the list. This all sounds like gibberish. Please expand and if necessary explain acronyms when first used in each commit log / cover letter. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas
On Tue, Feb 02, 2021 at 02:55:44PM -0600, Rob Herring wrote: > Properties in if/then schemas weren't getting checked by the meta-schemas. > Enabling meta-schema checks finds several errors. > > The use of an 'items' schema (as opposed to the list form) is wrong in > some cases as it applies to all entries. 'contains' is the correct schema > to use in the case of multiple entries. > > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Eric Anholt > Cc: Nicolas Saenz Julienne > Cc: Florian Fainelli > Cc: Ray Jui > Cc: Scott Branden > Cc: Pavel Machek > Cc: Ulf Hansson > Cc: Kishon Vijay Abraham I > Cc: Vinod Koul > Cc: Geert Uytterhoeven > Cc: Linus Walleij > Cc: Daniel Lezcano > Cc: linux-cry...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Cc: linux-l...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
On Tue, Feb 02, 2021 at 04:33:56PM -0800, Stephen Boyd wrote: > Quoting Rob Herring (2021-02-02 12:55:42) > > > > diff --git > > a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > > > b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > index fa0ee03a527f..53cc6df0df96 100644 > > --- > > a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > +++ > > b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml > > @@ -18,7 +18,7 @@ properties: > > const: 1 > > > >compatible: > > -const: allwinner,sun9i-a80-usb-clocks > > +const: allwinner,sun9i-a80-usb-clks > > Should the file name change too? Ideally yes, and with that change Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] dt-bindings: Fix errors in 'if' schemas
Hi Rob,
On Tue, Feb 2, 2021 at 9:55 PM Rob Herring wrote:
> Properties in if/then schemas weren't getting checked by the meta-schemas.
> Enabling meta-schema checks finds several errors.
>
> The use of an 'items' schema (as opposed to the list form) is wrong in
> some cases as it applies to all entries. 'contains' is the correct schema
> to use in the case of multiple entries.
> Signed-off-by: Rob Herring
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
> @@ -81,9 +81,8 @@ properties:
> if:
>properties:
> compatible:
> - items:
> -enum:
> - - renesas,usb2-phy-r7s9210
> + contains:
> +const: renesas,usb2-phy-r7s9210
Single entry, so "contains" not needed?
> --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml
> @@ -76,11 +76,10 @@ required:
> if:
>properties:
> compatible:
> - items:
> -enum:
> - - renesas,pfc-r8a73a4
> - - renesas,pfc-r8a7740
> - - renesas,pfc-sh73a0
> + enum:
> +- renesas,pfc-r8a73a4
> +- renesas,pfc-r8a7740
> +- renesas,pfc-sh73a0
Missing "contains"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
