All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-08  7:42 ` Kai-Heng Feng
  0 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-07-08  7:42 UTC (permalink / raw)
  To: joro, will
  Cc: Kai-Heng Feng, Robin Murphy, open list:AMD IOMMU (AMD-VI), open list

We are seeing kernel panic on rtw88 probe routine because swiotlb isn't
set:
[  252.036773] rtw_8821ce 0000:06:00.0: enabling device (0000 -> 0003)
[  252.037084] Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
[  252.037146] CPU: 7 PID: 1174 Comm: modprobe Not tainted 5.13.0+ #39
[  252.037175] Hardware name: HP HP ProDesk 405 G6 Small Form Factor PC/8835, BIOS S05 Ver. 02.04.00 06/03/2021
[  252.037218] Call Trace:
[  252.037231]  dump_stack_lvl+0x4a/0x5f
[  252.037251]  dump_stack+0x10/0x12
[  252.037267]  panic+0x101/0x2e3
[  252.037284]  swiotlb_tbl_map_single.cold+0xc/0x73
[  252.037305]  ? __mod_lruvec_page_state+0x95/0xb0
[  252.037329]  ? kmalloc_large_node+0x8c/0xb0
[  252.037348]  ? __netdev_alloc_skb+0x44/0x160
[  252.037370]  swiotlb_map+0x61/0x240
[  252.037387]  ? __alloc_skb+0xed/0x1e0
[  252.037404]  dma_map_page_attrs+0x12c/0x1f0
[  252.037422]  ? __netdev_alloc_skb+0x44/0x160
[  252.037443]  rtw_pci_probe+0x30f/0x872 [rtw88_pci]
[  252.037467]  local_pci_probe+0x48/0x80
[  252.037487]  pci_device_probe+0x105/0x1c0
[  252.037506]  really_probe+0x1fe/0x3f0
[  252.037524]  __driver_probe_device+0x109/0x180
[  252.037545]  driver_probe_device+0x23/0x90
[  252.037564]  __driver_attach+0xac/0x1b0
[  252.037582]  ? __device_attach_driver+0xe0/0xe0
[  252.037602]  bus_for_each_dev+0x7e/0xc0
[  252.037620]  driver_attach+0x1e/0x20
[  252.037637]  bus_add_driver+0x135/0x1f0
[  252.037654]  driver_register+0x95/0xf0
[  252.037672]  ? 0xffffffffc0fa0000
[  252.037687]  __pci_register_driver+0x68/0x70
[  252.037707]  rtw_8821ce_driver_init+0x23/0x1000 [rtw88_8821ce]
[  252.037734]  do_one_initcall+0x48/0x1d0
[  252.037752]  ? __cond_resched+0x1a/0x50
[  252.037771]  ? kmem_cache_alloc_trace+0x29d/0x3c0
[  252.037792]  do_init_module+0x62/0x280
[  252.037810]  load_module+0x2577/0x27c0
[  252.037862]  __do_sys_finit_module+0xbf/0x120
[  252.037877]  __x64_sys_finit_module+0x1a/0x20
[  252.037893]  do_syscall_64+0x3b/0xc0
[  252.037907]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  252.037925] RIP: 0033:0x7ff5a2f9408d
[  252.037938] Code: 27 0d 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab dd 0c 00 f7 d8 64 89 01 48
[  252.037993] RSP: 002b:00007fffaa89dce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  252.038017] RAX: ffffffffffffffda RBX: 000055fd4f881080 RCX: 00007ff5a2f9408d
[  252.038039] RDX: 0000000000000000 RSI: 000055fd4f63ec02 RDI: 0000000000000009
[  252.038063] RBP: 0000000000040000 R08: 0000000000000000 R09: 000055fd4f8885b0
[  252.038085] R10: 0000000000000009 R11: 0000000000000246 R12: 000055fd4f63ec02
[  252.038107] R13: 000055fd4f881120 R14: 0000000000000000 R15: 000055fd4f88e350
[  252.038293] Kernel Offset: 0x30600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Because the Realtek WiFi (PCI 06:00.0) is in the same IOMMU group as AMD
graphics (PCI 01:00.0),
[    1.326166] pci 0000:01:00.0: Adding to iommu group 0
...
[    1.326268] pci 0000:06:00.0: Adding to iommu group 0

And the AMD graphics supports iommu v2, so the group uses intentity
mapping based on the query from amd_iommu_def_domain_type().

However, the Realtek WiFi doesn't support 64bit DMA, so we need to
enable swiotlb, which was disabled by amd_iommu_init_dma_ops(), to make
remapping work.

Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/iommu/amd/iommu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 811a49a95d04..7c5111ed5c97 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
 
 		iommu = amd_iommu_rlookup_table[dev_data->devid];
 		dev_data->iommu_v2 = iommu->is_iommu_v2;
+
+		if (dev_data->iommu_v2)
+			swiotlb = 1;
 	}
 
 	dev_iommu_priv_set(dev, dev_data);
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-08  7:42 ` Kai-Heng Feng
  0 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-07-08  7:42 UTC (permalink / raw)
  To: joro, will
  Cc: open list:AMD IOMMU AMD-VI, Kai-Heng Feng, Robin Murphy, open list

We are seeing kernel panic on rtw88 probe routine because swiotlb isn't
set:
[  252.036773] rtw_8821ce 0000:06:00.0: enabling device (0000 -> 0003)
[  252.037084] Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
[  252.037146] CPU: 7 PID: 1174 Comm: modprobe Not tainted 5.13.0+ #39
[  252.037175] Hardware name: HP HP ProDesk 405 G6 Small Form Factor PC/8835, BIOS S05 Ver. 02.04.00 06/03/2021
[  252.037218] Call Trace:
[  252.037231]  dump_stack_lvl+0x4a/0x5f
[  252.037251]  dump_stack+0x10/0x12
[  252.037267]  panic+0x101/0x2e3
[  252.037284]  swiotlb_tbl_map_single.cold+0xc/0x73
[  252.037305]  ? __mod_lruvec_page_state+0x95/0xb0
[  252.037329]  ? kmalloc_large_node+0x8c/0xb0
[  252.037348]  ? __netdev_alloc_skb+0x44/0x160
[  252.037370]  swiotlb_map+0x61/0x240
[  252.037387]  ? __alloc_skb+0xed/0x1e0
[  252.037404]  dma_map_page_attrs+0x12c/0x1f0
[  252.037422]  ? __netdev_alloc_skb+0x44/0x160
[  252.037443]  rtw_pci_probe+0x30f/0x872 [rtw88_pci]
[  252.037467]  local_pci_probe+0x48/0x80
[  252.037487]  pci_device_probe+0x105/0x1c0
[  252.037506]  really_probe+0x1fe/0x3f0
[  252.037524]  __driver_probe_device+0x109/0x180
[  252.037545]  driver_probe_device+0x23/0x90
[  252.037564]  __driver_attach+0xac/0x1b0
[  252.037582]  ? __device_attach_driver+0xe0/0xe0
[  252.037602]  bus_for_each_dev+0x7e/0xc0
[  252.037620]  driver_attach+0x1e/0x20
[  252.037637]  bus_add_driver+0x135/0x1f0
[  252.037654]  driver_register+0x95/0xf0
[  252.037672]  ? 0xffffffffc0fa0000
[  252.037687]  __pci_register_driver+0x68/0x70
[  252.037707]  rtw_8821ce_driver_init+0x23/0x1000 [rtw88_8821ce]
[  252.037734]  do_one_initcall+0x48/0x1d0
[  252.037752]  ? __cond_resched+0x1a/0x50
[  252.037771]  ? kmem_cache_alloc_trace+0x29d/0x3c0
[  252.037792]  do_init_module+0x62/0x280
[  252.037810]  load_module+0x2577/0x27c0
[  252.037862]  __do_sys_finit_module+0xbf/0x120
[  252.037877]  __x64_sys_finit_module+0x1a/0x20
[  252.037893]  do_syscall_64+0x3b/0xc0
[  252.037907]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  252.037925] RIP: 0033:0x7ff5a2f9408d
[  252.037938] Code: 27 0d 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab dd 0c 00 f7 d8 64 89 01 48
[  252.037993] RSP: 002b:00007fffaa89dce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  252.038017] RAX: ffffffffffffffda RBX: 000055fd4f881080 RCX: 00007ff5a2f9408d
[  252.038039] RDX: 0000000000000000 RSI: 000055fd4f63ec02 RDI: 0000000000000009
[  252.038063] RBP: 0000000000040000 R08: 0000000000000000 R09: 000055fd4f8885b0
[  252.038085] R10: 0000000000000009 R11: 0000000000000246 R12: 000055fd4f63ec02
[  252.038107] R13: 000055fd4f881120 R14: 0000000000000000 R15: 000055fd4f88e350
[  252.038293] Kernel Offset: 0x30600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

Because the Realtek WiFi (PCI 06:00.0) is in the same IOMMU group as AMD
graphics (PCI 01:00.0),
[    1.326166] pci 0000:01:00.0: Adding to iommu group 0
...
[    1.326268] pci 0000:06:00.0: Adding to iommu group 0

And the AMD graphics supports iommu v2, so the group uses intentity
mapping based on the query from amd_iommu_def_domain_type().

However, the Realtek WiFi doesn't support 64bit DMA, so we need to
enable swiotlb, which was disabled by amd_iommu_init_dma_ops(), to make
remapping work.

Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
 drivers/iommu/amd/iommu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 811a49a95d04..7c5111ed5c97 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
 
 		iommu = amd_iommu_rlookup_table[dev_data->devid];
 		dev_data->iommu_v2 = iommu->is_iommu_v2;
+
+		if (dev_data->iommu_v2)
+			swiotlb = 1;
 	}
 
 	dev_iommu_priv_set(dev, dev_data);
-- 
2.31.1

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-08  7:42 ` Kai-Heng Feng
@ 2021-07-08  9:28   ` Joerg Roedel
  -1 siblings, 0 replies; 18+ messages in thread
From: Joerg Roedel @ 2021-07-08  9:28 UTC (permalink / raw)
  To: Kai-Heng Feng; +Cc: will, Robin Murphy, open list:AMD IOMMU (AMD-VI), open list

On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>  
>  		iommu = amd_iommu_rlookup_table[dev_data->devid];
>  		dev_data->iommu_v2 = iommu->is_iommu_v2;
> +
> +		if (dev_data->iommu_v2)
> +			swiotlb = 1;

This looks like the big hammer, as it will affect all other systems
where the AMD GPUs are in their own group.

What is needed here is an explicit check whether a non-iommu-v2 device
is direct-mapped because it shares a group with the GPU, and only enable
swiotlb in this case.

Thanks,

	Joerg

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-08  9:28   ` Joerg Roedel
  0 siblings, 0 replies; 18+ messages in thread
From: Joerg Roedel @ 2021-07-08  9:28 UTC (permalink / raw)
  To: Kai-Heng Feng; +Cc: Robin Murphy, open list:AMD IOMMU (AMD-VI), will, open list

On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>  
>  		iommu = amd_iommu_rlookup_table[dev_data->devid];
>  		dev_data->iommu_v2 = iommu->is_iommu_v2;
> +
> +		if (dev_data->iommu_v2)
> +			swiotlb = 1;

This looks like the big hammer, as it will affect all other systems
where the AMD GPUs are in their own group.

What is needed here is an explicit check whether a non-iommu-v2 device
is direct-mapped because it shares a group with the GPU, and only enable
swiotlb in this case.

Thanks,

	Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-08  9:28   ` Joerg Roedel
@ 2021-07-08 10:18     ` Robin Murphy
  -1 siblings, 0 replies; 18+ messages in thread
From: Robin Murphy @ 2021-07-08 10:18 UTC (permalink / raw)
  To: Joerg Roedel, Kai-Heng Feng; +Cc: will, open list:AMD IOMMU (AMD-VI), open list

On 2021-07-08 10:28, Joerg Roedel wrote:
> On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
>> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>>   
>>   		iommu = amd_iommu_rlookup_table[dev_data->devid];
>>   		dev_data->iommu_v2 = iommu->is_iommu_v2;
>> +
>> +		if (dev_data->iommu_v2)
>> +			swiotlb = 1;
> 
> This looks like the big hammer, as it will affect all other systems
> where the AMD GPUs are in their own group.
> 
> What is needed here is an explicit check whether a non-iommu-v2 device
> is direct-mapped because it shares a group with the GPU, and only enable
> swiotlb in this case.

Right, it's basically about whether any DMA-limited device might at any 
time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the 
possibility of device hotplug and the user being silly with the sysfs 
interface, I don't think we can categorically determine that at boot time.

Also note that Intel systems are likely to be similarly affected (in 
fact intel-iommu doesn't even have the iommu_default_passthough() check 
so it's probably even easier to blow up).

Robin.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-08 10:18     ` Robin Murphy
  0 siblings, 0 replies; 18+ messages in thread
From: Robin Murphy @ 2021-07-08 10:18 UTC (permalink / raw)
  To: Joerg Roedel, Kai-Heng Feng; +Cc: open list:AMD IOMMU (AMD-VI), will, open list

On 2021-07-08 10:28, Joerg Roedel wrote:
> On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
>> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>>   
>>   		iommu = amd_iommu_rlookup_table[dev_data->devid];
>>   		dev_data->iommu_v2 = iommu->is_iommu_v2;
>> +
>> +		if (dev_data->iommu_v2)
>> +			swiotlb = 1;
> 
> This looks like the big hammer, as it will affect all other systems
> where the AMD GPUs are in their own group.
> 
> What is needed here is an explicit check whether a non-iommu-v2 device
> is direct-mapped because it shares a group with the GPU, and only enable
> swiotlb in this case.

Right, it's basically about whether any DMA-limited device might at any 
time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the 
possibility of device hotplug and the user being silly with the sysfs 
interface, I don't think we can categorically determine that at boot time.

Also note that Intel systems are likely to be similarly affected (in 
fact intel-iommu doesn't even have the iommu_default_passthough() check 
so it's probably even easier to blow up).

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-08 10:18     ` Robin Murphy
@ 2021-07-08 13:57       ` Kai-Heng Feng
  -1 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-07-08 13:57 UTC (permalink / raw)
  To: Robin Murphy; +Cc: Joerg Roedel, will, open list:AMD IOMMU (AMD-VI), open list

On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-07-08 10:28, Joerg Roedel wrote:
> > On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> >> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
> >>
> >>              iommu = amd_iommu_rlookup_table[dev_data->devid];
> >>              dev_data->iommu_v2 = iommu->is_iommu_v2;
> >> +
> >> +            if (dev_data->iommu_v2)
> >> +                    swiotlb = 1;
> >
> > This looks like the big hammer, as it will affect all other systems
> > where the AMD GPUs are in their own group.
> >
> > What is needed here is an explicit check whether a non-iommu-v2 device
> > is direct-mapped because it shares a group with the GPU, and only enable
> > swiotlb in this case.
>
> Right, it's basically about whether any DMA-limited device might at any
> time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
> possibility of device hotplug and the user being silly with the sysfs
> interface, I don't think we can categorically determine that at boot time.
>
> Also note that Intel systems are likely to be similarly affected (in
> fact intel-iommu doesn't even have the iommu_default_passthough() check
> so it's probably even easier to blow up).

swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
disable it.

I wonder if we can take the same approach in amd-iommu?

Kai-Heng

>
> Robin.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-08 13:57       ` Kai-Heng Feng
  0 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-07-08 13:57 UTC (permalink / raw)
  To: Robin Murphy; +Cc: will, open list:AMD IOMMU (AMD-VI), open list

On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-07-08 10:28, Joerg Roedel wrote:
> > On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> >> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
> >>
> >>              iommu = amd_iommu_rlookup_table[dev_data->devid];
> >>              dev_data->iommu_v2 = iommu->is_iommu_v2;
> >> +
> >> +            if (dev_data->iommu_v2)
> >> +                    swiotlb = 1;
> >
> > This looks like the big hammer, as it will affect all other systems
> > where the AMD GPUs are in their own group.
> >
> > What is needed here is an explicit check whether a non-iommu-v2 device
> > is direct-mapped because it shares a group with the GPU, and only enable
> > swiotlb in this case.
>
> Right, it's basically about whether any DMA-limited device might at any
> time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
> possibility of device hotplug and the user being silly with the sysfs
> interface, I don't think we can categorically determine that at boot time.
>
> Also note that Intel systems are likely to be similarly affected (in
> fact intel-iommu doesn't even have the iommu_default_passthough() check
> so it's probably even easier to blow up).

swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
disable it.

I wonder if we can take the same approach in amd-iommu?

Kai-Heng

>
> Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-08 13:57       ` Kai-Heng Feng
@ 2021-07-08 14:43         ` Robin Murphy
  -1 siblings, 0 replies; 18+ messages in thread
From: Robin Murphy @ 2021-07-08 14:43 UTC (permalink / raw)
  To: Kai-Heng Feng; +Cc: will, open list:AMD IOMMU (AMD-VI), open list, Joerg Roedel

On 2021-07-08 14:57, Kai-Heng Feng wrote:
> On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2021-07-08 10:28, Joerg Roedel wrote:
>>> On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
>>>> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>>>>
>>>>               iommu = amd_iommu_rlookup_table[dev_data->devid];
>>>>               dev_data->iommu_v2 = iommu->is_iommu_v2;
>>>> +
>>>> +            if (dev_data->iommu_v2)
>>>> +                    swiotlb = 1;
>>>
>>> This looks like the big hammer, as it will affect all other systems
>>> where the AMD GPUs are in their own group.
>>>
>>> What is needed here is an explicit check whether a non-iommu-v2 device
>>> is direct-mapped because it shares a group with the GPU, and only enable
>>> swiotlb in this case.
>>
>> Right, it's basically about whether any DMA-limited device might at any
>> time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
>> possibility of device hotplug and the user being silly with the sysfs
>> interface, I don't think we can categorically determine that at boot time.
>>
>> Also note that Intel systems are likely to be similarly affected (in
>> fact intel-iommu doesn't even have the iommu_default_passthough() check
>> so it's probably even easier to blow up).
> 
> swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> disable it.

Oh, right... I did say I found this dance hard to follow. Clearly I 
shouldn't have trusted what I thought I remembered from looking at it 
yesterday :)

Also not helped by the fact that it sets iommu_detected which *does* 
disable SWIOTLB, but only on IA-64.

> I wonder if we can take the same approach in amd-iommu?

Certainly if there's a precedent for leaving SWIOTLB enabled even if it 
*might* be redundant, that seems like the easiest option (it's what we 
do on arm64 too, but then we have system topologies where some devices 
may not be behind IOMMUs even when others are). More fun would be to try 
to bring it up at the first sign of IOMMU_DOMAIN_IDENTITY if it was 
disabled previously, but I don't have the highest hope of that being 
practical.

Robin.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-08 14:43         ` Robin Murphy
  0 siblings, 0 replies; 18+ messages in thread
From: Robin Murphy @ 2021-07-08 14:43 UTC (permalink / raw)
  To: Kai-Heng Feng; +Cc: open list:AMD IOMMU (AMD-VI), will, open list

On 2021-07-08 14:57, Kai-Heng Feng wrote:
> On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2021-07-08 10:28, Joerg Roedel wrote:
>>> On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
>>>> @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
>>>>
>>>>               iommu = amd_iommu_rlookup_table[dev_data->devid];
>>>>               dev_data->iommu_v2 = iommu->is_iommu_v2;
>>>> +
>>>> +            if (dev_data->iommu_v2)
>>>> +                    swiotlb = 1;
>>>
>>> This looks like the big hammer, as it will affect all other systems
>>> where the AMD GPUs are in their own group.
>>>
>>> What is needed here is an explicit check whether a non-iommu-v2 device
>>> is direct-mapped because it shares a group with the GPU, and only enable
>>> swiotlb in this case.
>>
>> Right, it's basically about whether any DMA-limited device might at any
>> time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
>> possibility of device hotplug and the user being silly with the sysfs
>> interface, I don't think we can categorically determine that at boot time.
>>
>> Also note that Intel systems are likely to be similarly affected (in
>> fact intel-iommu doesn't even have the iommu_default_passthough() check
>> so it's probably even easier to blow up).
> 
> swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> disable it.

Oh, right... I did say I found this dance hard to follow. Clearly I 
shouldn't have trusted what I thought I remembered from looking at it 
yesterday :)

Also not helped by the fact that it sets iommu_detected which *does* 
disable SWIOTLB, but only on IA-64.

> I wonder if we can take the same approach in amd-iommu?

Certainly if there's a precedent for leaving SWIOTLB enabled even if it 
*might* be redundant, that seems like the easiest option (it's what we 
do on arm64 too, but then we have system topologies where some devices 
may not be behind IOMMUs even when others are). More fun would be to try 
to bring it up at the first sign of IOMMU_DOMAIN_IDENTITY if it was 
disabled previously, but I don't have the highest hope of that being 
practical.

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-08 14:43         ` Robin Murphy
@ 2021-07-13 23:57           ` Konrad Rzeszutek Wilk
  -1 siblings, 0 replies; 18+ messages in thread
From: Konrad Rzeszutek Wilk @ 2021-07-13 23:57 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Kai-Heng Feng, will, open list:AMD IOMMU (AMD-VI),
	open list, Joerg Roedel

On Thu, Jul 08, 2021 at 03:43:42PM +0100, Robin Murphy wrote:
> On 2021-07-08 14:57, Kai-Heng Feng wrote:
> > On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > 
> > > On 2021-07-08 10:28, Joerg Roedel wrote:
> > > > On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> > > > > @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
> > > > > 
> > > > >               iommu = amd_iommu_rlookup_table[dev_data->devid];
> > > > >               dev_data->iommu_v2 = iommu->is_iommu_v2;
> > > > > +
> > > > > +            if (dev_data->iommu_v2)
> > > > > +                    swiotlb = 1;
> > > > 
> > > > This looks like the big hammer, as it will affect all other systems
> > > > where the AMD GPUs are in their own group.
> > > > 
> > > > What is needed here is an explicit check whether a non-iommu-v2 device
> > > > is direct-mapped because it shares a group with the GPU, and only enable
> > > > swiotlb in this case.
> > > 
> > > Right, it's basically about whether any DMA-limited device might at any
> > > time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
> > > possibility of device hotplug and the user being silly with the sysfs
> > > interface, I don't think we can categorically determine that at boot time.
> > > 
> > > Also note that Intel systems are likely to be similarly affected (in
> > > fact intel-iommu doesn't even have the iommu_default_passthough() check
> > > so it's probably even easier to blow up).
> > 
> > swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> > disable it.
> 
> Oh, right... I did say I found this dance hard to follow. Clearly I
> shouldn't have trusted what I thought I remembered from looking at it
> yesterday :)
> 
> Also not helped by the fact that it sets iommu_detected which *does* disable
> SWIOTLB, but only on IA-64.
> 
> > I wonder if we can take the same approach in amd-iommu?
> 
> Certainly if there's a precedent for leaving SWIOTLB enabled even if it
> *might* be redundant, that seems like the easiest option (it's what we do on
> arm64 too, but then we have system topologies where some devices may not be
> behind IOMMUs even when others are). More fun would be to try to bring it up
> at the first sign of IOMMU_DOMAIN_IDENTITY if it was disabled previously,
> but I don't have the highest hope of that being practical.

<scratches his head>
It is kind of silly to enable SWIOTLB which will just eat 64MB of memory
"just in case".

The SWIOTLB does have support to do late initialization (xen-pcifront
does that for example - so if you add devices that can't do 64-bit it
will allocate something like 4MB).

Would that be a better choice going forward - that is allocate this
under those conditions?
> 
> Robin.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-13 23:57           ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 18+ messages in thread
From: Konrad Rzeszutek Wilk @ 2021-07-13 23:57 UTC (permalink / raw)
  To: Robin Murphy; +Cc: open list:AMD IOMMU (AMD-VI), Kai-Heng Feng, will, open list

On Thu, Jul 08, 2021 at 03:43:42PM +0100, Robin Murphy wrote:
> On 2021-07-08 14:57, Kai-Heng Feng wrote:
> > On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > 
> > > On 2021-07-08 10:28, Joerg Roedel wrote:
> > > > On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> > > > > @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
> > > > > 
> > > > >               iommu = amd_iommu_rlookup_table[dev_data->devid];
> > > > >               dev_data->iommu_v2 = iommu->is_iommu_v2;
> > > > > +
> > > > > +            if (dev_data->iommu_v2)
> > > > > +                    swiotlb = 1;
> > > > 
> > > > This looks like the big hammer, as it will affect all other systems
> > > > where the AMD GPUs are in their own group.
> > > > 
> > > > What is needed here is an explicit check whether a non-iommu-v2 device
> > > > is direct-mapped because it shares a group with the GPU, and only enable
> > > > swiotlb in this case.
> > > 
> > > Right, it's basically about whether any DMA-limited device might at any
> > > time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
> > > possibility of device hotplug and the user being silly with the sysfs
> > > interface, I don't think we can categorically determine that at boot time.
> > > 
> > > Also note that Intel systems are likely to be similarly affected (in
> > > fact intel-iommu doesn't even have the iommu_default_passthough() check
> > > so it's probably even easier to blow up).
> > 
> > swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> > disable it.
> 
> Oh, right... I did say I found this dance hard to follow. Clearly I
> shouldn't have trusted what I thought I remembered from looking at it
> yesterday :)
> 
> Also not helped by the fact that it sets iommu_detected which *does* disable
> SWIOTLB, but only on IA-64.
> 
> > I wonder if we can take the same approach in amd-iommu?
> 
> Certainly if there's a precedent for leaving SWIOTLB enabled even if it
> *might* be redundant, that seems like the easiest option (it's what we do on
> arm64 too, but then we have system topologies where some devices may not be
> behind IOMMUs even when others are). More fun would be to try to bring it up
> at the first sign of IOMMU_DOMAIN_IDENTITY if it was disabled previously,
> but I don't have the highest hope of that being practical.

<scratches his head>
It is kind of silly to enable SWIOTLB which will just eat 64MB of memory
"just in case".

The SWIOTLB does have support to do late initialization (xen-pcifront
does that for example - so if you add devices that can't do 64-bit it
will allocate something like 4MB).

Would that be a better choice going forward - that is allocate this
under those conditions?
> 
> Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-13 23:57           ` Konrad Rzeszutek Wilk
@ 2021-07-14  4:59             ` Kai-Heng Feng
  -1 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-07-14  4:59 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Robin Murphy, will, open list:AMD IOMMU (AMD-VI),
	open list, Joerg Roedel

On Wed, Jul 14, 2021 at 7:57 AM Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>
> On Thu, Jul 08, 2021 at 03:43:42PM +0100, Robin Murphy wrote:
> > On 2021-07-08 14:57, Kai-Heng Feng wrote:
> > > On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >
> > > > On 2021-07-08 10:28, Joerg Roedel wrote:
> > > > > On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> > > > > > @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
> > > > > >
> > > > > >               iommu = amd_iommu_rlookup_table[dev_data->devid];
> > > > > >               dev_data->iommu_v2 = iommu->is_iommu_v2;
> > > > > > +
> > > > > > +            if (dev_data->iommu_v2)
> > > > > > +                    swiotlb = 1;
> > > > >
> > > > > This looks like the big hammer, as it will affect all other systems
> > > > > where the AMD GPUs are in their own group.
> > > > >
> > > > > What is needed here is an explicit check whether a non-iommu-v2 device
> > > > > is direct-mapped because it shares a group with the GPU, and only enable
> > > > > swiotlb in this case.
> > > >
> > > > Right, it's basically about whether any DMA-limited device might at any
> > > > time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
> > > > possibility of device hotplug and the user being silly with the sysfs
> > > > interface, I don't think we can categorically determine that at boot time.
> > > >
> > > > Also note that Intel systems are likely to be similarly affected (in
> > > > fact intel-iommu doesn't even have the iommu_default_passthough() check
> > > > so it's probably even easier to blow up).
> > >
> > > swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> > > disable it.
> >
> > Oh, right... I did say I found this dance hard to follow. Clearly I
> > shouldn't have trusted what I thought I remembered from looking at it
> > yesterday :)
> >
> > Also not helped by the fact that it sets iommu_detected which *does* disable
> > SWIOTLB, but only on IA-64.
> >
> > > I wonder if we can take the same approach in amd-iommu?
> >
> > Certainly if there's a precedent for leaving SWIOTLB enabled even if it
> > *might* be redundant, that seems like the easiest option (it's what we do on
> > arm64 too, but then we have system topologies where some devices may not be
> > behind IOMMUs even when others are). More fun would be to try to bring it up
> > at the first sign of IOMMU_DOMAIN_IDENTITY if it was disabled previously,
> > but I don't have the highest hope of that being practical.
>
> <scratches his head>
> It is kind of silly to enable SWIOTLB which will just eat 64MB of memory
> "just in case".
>
> The SWIOTLB does have support to do late initialization (xen-pcifront
> does that for example - so if you add devices that can't do 64-bit it
> will allocate something like 4MB).
>
> Would that be a better choice going forward - that is allocate this
> under those conditions?

But how to practically do swiotlb late init on 32-bit capable devices?
On the first DMA map requested by the driver?

Kai-Heng

> >
> > Robin.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-14  4:59             ` Kai-Heng Feng
  0 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-07-14  4:59 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: will, open list:AMD IOMMU (AMD-VI), Robin Murphy, open list

On Wed, Jul 14, 2021 at 7:57 AM Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>
> On Thu, Jul 08, 2021 at 03:43:42PM +0100, Robin Murphy wrote:
> > On 2021-07-08 14:57, Kai-Heng Feng wrote:
> > > On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >
> > > > On 2021-07-08 10:28, Joerg Roedel wrote:
> > > > > On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
> > > > > > @@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
> > > > > >
> > > > > >               iommu = amd_iommu_rlookup_table[dev_data->devid];
> > > > > >               dev_data->iommu_v2 = iommu->is_iommu_v2;
> > > > > > +
> > > > > > +            if (dev_data->iommu_v2)
> > > > > > +                    swiotlb = 1;
> > > > >
> > > > > This looks like the big hammer, as it will affect all other systems
> > > > > where the AMD GPUs are in their own group.
> > > > >
> > > > > What is needed here is an explicit check whether a non-iommu-v2 device
> > > > > is direct-mapped because it shares a group with the GPU, and only enable
> > > > > swiotlb in this case.
> > > >
> > > > Right, it's basically about whether any DMA-limited device might at any
> > > > time end up in an IOMMU_DOMAIN_IDENTITY domain. And given the
> > > > possibility of device hotplug and the user being silly with the sysfs
> > > > interface, I don't think we can categorically determine that at boot time.
> > > >
> > > > Also note that Intel systems are likely to be similarly affected (in
> > > > fact intel-iommu doesn't even have the iommu_default_passthough() check
> > > > so it's probably even easier to blow up).
> > >
> > > swiotlb is enabled by pci_swiotlb_detect_4gb() and intel-iommu doesn't
> > > disable it.
> >
> > Oh, right... I did say I found this dance hard to follow. Clearly I
> > shouldn't have trusted what I thought I remembered from looking at it
> > yesterday :)
> >
> > Also not helped by the fact that it sets iommu_detected which *does* disable
> > SWIOTLB, but only on IA-64.
> >
> > > I wonder if we can take the same approach in amd-iommu?
> >
> > Certainly if there's a precedent for leaving SWIOTLB enabled even if it
> > *might* be redundant, that seems like the easiest option (it's what we do on
> > arm64 too, but then we have system topologies where some devices may not be
> > behind IOMMUs even when others are). More fun would be to try to bring it up
> > at the first sign of IOMMU_DOMAIN_IDENTITY if it was disabled previously,
> > but I don't have the highest hope of that being practical.
>
> <scratches his head>
> It is kind of silly to enable SWIOTLB which will just eat 64MB of memory
> "just in case".
>
> The SWIOTLB does have support to do late initialization (xen-pcifront
> does that for example - so if you add devices that can't do 64-bit it
> will allocate something like 4MB).
>
> Would that be a better choice going forward - that is allocate this
> under those conditions?

But how to practically do swiotlb late init on 32-bit capable devices?
On the first DMA map requested by the driver?

Kai-Heng

> >
> > Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-13 23:57           ` Konrad Rzeszutek Wilk
@ 2021-07-14 10:25             ` Joerg Roedel
  -1 siblings, 0 replies; 18+ messages in thread
From: Joerg Roedel @ 2021-07-14 10:25 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Robin Murphy, Kai-Heng Feng, will, open list:AMD IOMMU (AMD-VI),
	open list

On Tue, Jul 13, 2021 at 07:57:40PM -0400, Konrad Rzeszutek Wilk wrote:
> The SWIOTLB does have support to do late initialization (xen-pcifront
> does that for example - so if you add devices that can't do 64-bit it
> will allocate something like 4MB).

That sounds like a way to evaluate. I suggest to allocate the SWIOTLB
memory at boot and when the IOMMUs are initialized we re-evaluate what
we ended up with and free the SWIOTLB memory if its not needed.

If that turns out to be wrong during runtime (e.g. because a device is
switched to a passthrough default domain at runtime), we allocate a
small aperture for this device like the above mentioned 4MB.

(A boot option to always keep the aperture around might also be helpful
 for some setups)

Regards,

	Joerg

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-07-14 10:25             ` Joerg Roedel
  0 siblings, 0 replies; 18+ messages in thread
From: Joerg Roedel @ 2021-07-14 10:25 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: will, open list:AMD IOMMU (AMD-VI),
	Kai-Heng Feng, Robin Murphy, open list

On Tue, Jul 13, 2021 at 07:57:40PM -0400, Konrad Rzeszutek Wilk wrote:
> The SWIOTLB does have support to do late initialization (xen-pcifront
> does that for example - so if you add devices that can't do 64-bit it
> will allocate something like 4MB).

That sounds like a way to evaluate. I suggest to allocate the SWIOTLB
memory at boot and when the IOMMUs are initialized we re-evaluate what
we ended up with and free the SWIOTLB memory if its not needed.

If that turns out to be wrong during runtime (e.g. because a device is
switched to a passthrough default domain at runtime), we allocate a
small aperture for this device like the above mentioned 4MB.

(A boot option to always keep the aperture around might also be helpful
 for some setups)

Regards,

	Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
  2021-07-14 10:25             ` Joerg Roedel
@ 2021-09-09  6:32               ` Kai-Heng Feng
  -1 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-09-09  6:32 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Konrad Rzeszutek Wilk, Robin Murphy, will,
	open list:AMD IOMMU (AMD-VI),
	open list

On Wed, Jul 14, 2021 at 6:25 PM Joerg Roedel <joro@8bytes.org> wrote:
>
> On Tue, Jul 13, 2021 at 07:57:40PM -0400, Konrad Rzeszutek Wilk wrote:
> > The SWIOTLB does have support to do late initialization (xen-pcifront
> > does that for example - so if you add devices that can't do 64-bit it
> > will allocate something like 4MB).
>
> That sounds like a way to evaluate. I suggest to allocate the SWIOTLB
> memory at boot and when the IOMMUs are initialized we re-evaluate what
> we ended up with and free the SWIOTLB memory if its not needed.
>
> If that turns out to be wrong during runtime (e.g. because a device is
> switched to a passthrough default domain at runtime), we allocate a
> small aperture for this device like the above mentioned 4MB.

I am currently working on this but I found that 4MB is not enough,
16MB is the minimal size to make the device work.
How do I know the right SWIOTLB size for each device?

>
> (A boot option to always keep the aperture around might also be helpful
>  for some setups)

OK, will also implement this in next iteration.

Kai-Heng

>
> Regards,
>
>         Joerg

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping
@ 2021-09-09  6:32               ` Kai-Heng Feng
  0 siblings, 0 replies; 18+ messages in thread
From: Kai-Heng Feng @ 2021-09-09  6:32 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Konrad Rzeszutek Wilk, open list:AMD IOMMU (AMD-VI),
	Robin Murphy, open list, will

On Wed, Jul 14, 2021 at 6:25 PM Joerg Roedel <joro@8bytes.org> wrote:
>
> On Tue, Jul 13, 2021 at 07:57:40PM -0400, Konrad Rzeszutek Wilk wrote:
> > The SWIOTLB does have support to do late initialization (xen-pcifront
> > does that for example - so if you add devices that can't do 64-bit it
> > will allocate something like 4MB).
>
> That sounds like a way to evaluate. I suggest to allocate the SWIOTLB
> memory at boot and when the IOMMUs are initialized we re-evaluate what
> we ended up with and free the SWIOTLB memory if its not needed.
>
> If that turns out to be wrong during runtime (e.g. because a device is
> switched to a passthrough default domain at runtime), we allocate a
> small aperture for this device like the above mentioned 4MB.

I am currently working on this but I found that 4MB is not enough,
16MB is the minimal size to make the device work.
How do I know the right SWIOTLB size for each device?

>
> (A boot option to always keep the aperture around might also be helpful
>  for some setups)

OK, will also implement this in next iteration.

Kai-Heng

>
> Regards,
>
>         Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2021-09-09  6:53 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-08  7:42 [PATCH] iommu/amd: Enable swiotlb if any device supports iommu v2 and uses identity mapping Kai-Heng Feng
2021-07-08  7:42 ` Kai-Heng Feng
2021-07-08  9:28 ` Joerg Roedel
2021-07-08  9:28   ` Joerg Roedel
2021-07-08 10:18   ` Robin Murphy
2021-07-08 10:18     ` Robin Murphy
2021-07-08 13:57     ` Kai-Heng Feng
2021-07-08 13:57       ` Kai-Heng Feng
2021-07-08 14:43       ` Robin Murphy
2021-07-08 14:43         ` Robin Murphy
2021-07-13 23:57         ` Konrad Rzeszutek Wilk
2021-07-13 23:57           ` Konrad Rzeszutek Wilk
2021-07-14  4:59           ` Kai-Heng Feng
2021-07-14  4:59             ` Kai-Heng Feng
2021-07-14 10:25           ` Joerg Roedel
2021-07-14 10:25             ` Joerg Roedel
2021-09-09  6:32             ` Kai-Heng Feng
2021-09-09  6:32               ` Kai-Heng Feng

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.