[PATCH 1/1] iommu/amd: Fix typos for PPR macros
From: Adrian Huang The bit 13 and bit 14 of the IOMMU control register are PPRLogEn and PPRIntEn. They are related to PPR (Peripheral Page Request) instead of 'PPF'. Fix them accrodingly. Signed-off-by: Adrian Huang --- drivers/iommu/amd_iommu_init.c | 4 ++-- drivers/iommu/amd_iommu_types.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index ba7ee4aa04f9..6e82aa606e2b 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -716,7 +716,7 @@ static void iommu_enable_ppr_log(struct amd_iommu *iommu) writel(0x00, iommu->mmio_base + MMIO_PPR_HEAD_OFFSET); writel(0x00, iommu->mmio_base + MMIO_PPR_TAIL_OFFSET); - iommu_feature_enable(iommu, CONTROL_PPFLOG_EN); + iommu_feature_enable(iommu, CONTROL_PPRLOG_EN); iommu_feature_enable(iommu, CONTROL_PPR_EN); } @@ -2035,7 +2035,7 @@ static int iommu_init_msi(struct amd_iommu *iommu) iommu_feature_enable(iommu, CONTROL_EVT_INT_EN); if (iommu->ppr_log != NULL) - iommu_feature_enable(iommu, CONTROL_PPFINT_EN); + iommu_feature_enable(iommu, CONTROL_PPRINT_EN); iommu_ga_log_enable(iommu); diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h index 798e1533a147..500f0b78879d 100644 --- a/drivers/iommu/amd_iommu_types.h +++ b/drivers/iommu/amd_iommu_types.h @@ -147,8 +147,8 @@ #define CONTROL_COHERENT_EN 0x0aULL #define CONTROL_ISOC_EN 0x0bULL #define CONTROL_CMDBUF_EN 0x0cULL -#define CONTROL_PPFLOG_EN 0x0dULL -#define CONTROL_PPFINT_EN 0x0eULL +#define CONTROL_PPRLOG_EN 0x0dULL +#define CONTROL_PPRINT_EN 0x0eULL #define CONTROL_PPR_EN 0x0fULL #define CONTROL_GT_EN 0x10ULL #define CONTROL_GA_EN 0x11ULL -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d fix adding non-PCI devices to Intel IOMMU
Hi,
On 12/27/19 7:56 AM, Patrick Steinhardt wrote:
Starting with commit fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI
name space devices"), we now probe DMA-capable ACPI name
space devices. On Dell XPS 13 9343, which has an Intel LPSS platform
device INTL9C60 enumerated via ACPI, this change leads to the following
warning:
[ cut here ]
WARNING: CPU: 1 PID: 1 at pci_device_group+0x11a/0x130
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GT 5.5.0-rc3+ #22
Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A20 06/06/2019
RIP: 0010:pci_device_group+0x11a/0x130
Code: f0 ff ff 48 85 c0 49 89 c4 75 c4 48 8d 74 24 10 48 89 ef e8 48 ef ff ff 48
85 c0 49 89 c4 75 af e8 db f7 ff ff 49 89 c4 eb a5 <0f> 0b 49 c7 c4 ea ff ff ff
eb 9a e8 96 1e c7 ff 66 0f 1f 44 00 00
RSP: :c0d6c0043cb0 EFLAGS: 00010202
RAX: RBX: a3d1d43dd810 RCX:
RDX: a3d1d4fecf80 RSI: a3d12943dcc0 RDI: a3d1d43dd810
RBP: a3d1d43dd810 R08: R09: a3d1d4c04a80
R10: a3d1d4c00880 R11: a3d1d44ba000 R12:
R13: a3d1d4383b80 R14: a3d1d4c090d0 R15: a3d1d4324530
FS: () GS:a3d1d670()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 0460a001 CR4: 003606e0
Call Trace:
? iommu_group_get_for_dev+0x81/0x1f0
? intel_iommu_add_device+0x61/0x170
? iommu_probe_device+0x43/0xd0
? intel_iommu_init+0x1fa2/0x2235
? pci_iommu_init+0x52/0xe7
? e820__memblock_setup+0x15c/0x15c
? do_one_initcall+0xcc/0x27e
? kernel_init_freeable+0x169/0x259
? rest_init+0x95/0x95
? kernel_init+0x5/0xeb
? ret_from_fork+0x35/0x40
---[ end trace 28473e7abc25b92c ]---
DMAR: ACPI name space devices didn't probe correctly
The bug results from the fact that while we now enumerate ACPI devices,
we aren't able to handle any non-PCI device when generating the device
group. Fix the issue by implementing an Intel-specific callback that
returns `pci_device_group` only if the device is a PCI device.
Otherwise, it will return a generic device group.
Fixes: fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices")
Signed-off-by: Patrick Steinhardt
This will allocate per-device group for the ANDD device. Different
devices that couldn't be isolated should be put in a single group.
Unfortunately, the spec doesn't state how the ANDD devices are isolated.
Currently we don't support assigning a platform device to user level as
far as I can see, so though this fix is not the best, it won't break
anything. I will ack this fix so that the kernel crash could be fixed
before we figure out a better solution.
Cc: sta...@vger.kernel.org # v5.3+
Acked-by: Lu Baolu
Best regards,
-baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 5.4 368/434] iommu: set group default domain before creating direct mappings
From: Jerry Snitselaar
commit d360211524bece6db9920f32c91808235290b51c upstream.
iommu_group_create_direct_mappings uses group->default_domain, but
right after it is called, request_default_domain_for_dev calls
iommu_domain_free for the default domain, and sets the group default
domain to a different domain. Move the
iommu_group_create_direct_mappings call to after the group default
domain is set, so the direct mappings get associated with that domain.
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Cc: sta...@vger.kernel.org
Fixes: 7423e01741dd ("iommu: Add API to request DMA domain for device")
Signed-off-by: Jerry Snitselaar
Reviewed-by: Lu Baolu
Signed-off-by: Joerg Roedel
Signed-off-by: Greg Kroah-Hartman
---
drivers/iommu/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2221,13 +2221,13 @@ request_default_domain_for_dev(struct de
goto out;
}
- iommu_group_create_direct_mappings(group, dev);
-
/* Make the domain the default for this group */
if (group->default_domain)
iommu_domain_free(group->default_domain);
group->default_domain = domain;
+ iommu_group_create_direct_mappings(group, dev);
+
dev_info(dev, "Using iommu %s mapping\n",
type == IOMMU_DOMAIN_DMA ? "dma" : "direct");
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 5.4 371/434] iommu/vt-d: Allocate reserved region for ISA with correct permission
From: Jerry Snitselaar
commit cde9319e884eb6267a0df446f3c131fe1108defb upstream.
Currently the reserved region for ISA is allocated with no
permissions. If a dma domain is being used, mapping this region will
fail. Set the permissions to DMA_PTE_READ|DMA_PTE_WRITE.
Cc: Joerg Roedel
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Cc: sta...@vger.kernel.org # v5.3+
Fixes: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via
iommu_get_resv_regions")
Signed-off-by: Jerry Snitselaar
Acked-by: Lu Baolu
Signed-off-by: Joerg Roedel
Signed-off-by: Greg Kroah-Hartman
---
drivers/iommu/intel-iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5697,7 +5697,7 @@ static void intel_iommu_get_resv_regions
struct pci_dev *pdev = to_pci_dev(device);
if ((pdev->class >> 8) == PCI_CLASS_BRIDGE_ISA) {
- reg = iommu_alloc_resv_region(0, 1UL << 24, 0,
+ reg = iommu_alloc_resv_region(0, 1UL << 24, prot,
IOMMU_RESV_DIRECT_RELAXABLE);
if (reg)
list_add_tail(>list, head);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
