Re: PCI passthrough with multiple devices in same iommu group
Thanks for info
See inline
On Wed, Nov 28, 2018 at 8:56 PM Alex Williamson
wrote:
> On Wed, 28 Nov 2018 20:21:02 +0530
> gokul cg wrote:
>
> > Hi Folks,
> >
> > Please excuse me , I just writing to you as i could see you had made
> > changes regarding iommu and I thought you could give help me here.
> >
> > We are testing visualization with QEMU-2.7.0 + Linux-4.8+, we are facing
> > issue while configuring pass through PCI devices in QEMU to pass it to
> > guest OS.
> > We are using following QEMU argument to configure PCI device as
> passthrough
> > device to guest, which was working with Linux 3.10 distro (hypervisor:
> QEMU
> > 1.7.2, Linux: 3.10+).
> >
> > /usr/bin/qemu-system-x86_64 -name guest_1 -S -machine
> > pc-i440fx-1.7,accel=kvm,usb=off -m 49152\
> > -device kvm-pci-assign,host=:00:1f.3 -device
> > kvm-pci-assign,host=:09:0e.0 ..
>
> Legacy KVM device assignment (aka kvm-pci-assign) has been deprecated
> for some time now, you'll find it doesn't even exist in newer kernels
> and QEMU.
>
> Understood .
> > Here is the error message that we will get when we try to configure PCI
> > devices as passthrough using kvm pci assignment method in Linux 4.8+
> > (hypervisor: QEMU 2.7.0, Linux: 4.8+).
> >
> > which is shown below.
> >
> > ---log---
> >
> > From QEMU:
> > qemu-system-x86_64: -device kvm-pci-assign,host=:00:1f.3: Failed to
> > assign device "(null)": Invalid argument
> >
> > From dmesg:
> > pci-stub :00:1f.3: kvm assign device failed ret -22
> >
> > ---end
> >
> > Info about devices (CPU: Intel(R) Xeon(R) CPU E5-2608L):
> >
> > root@shining-node:~# lspci -k -s 00:1f.3
> > 00:1f.3 SMBus: Intel Corporation C610/X99 series chipset SMBus Controller
> > (rev 05)
> > Subsystem: Intel Corporation C610/X99 series chipset SMBus
> > Controller
> > Kernel driver in use: pci-stub
> > Kernel modules: i2c_i801
>
> Why are you trying to assign an SMBus controller to a VM?
>
> We want guest of to read out eprom and sensor devices and manage our
chassis .
Our i2c devices are connected to Intel SMbus controller
> root@shining-node:~#
> > root@shining-node:~# lspci -k -s 09:0e.0
> > 09:0e.0 Network controller: Broadcom Limited Device b680 (rev 12)
> > root@shining-node:~#
> >
> > From the web search i could see that it is because there are multiple
> > devices in same iommu_group that the passthrough device belongs to.
> > When i check iommu_group , i have multiple devices in same group but all
> > those are intel devices under Wellsburg PCH.
>
> Nope, kvm-pci-assign doesn't make use of IOMMU groups, more likely just
> some state of disrepair as it's deprecated and replaced by vfio-pci,
> which does use iommu groups. So iommu groups will be a problem, but
> not in the configuration you're attempting to use above.
>
> The error i had pasted above "< pci-stub :00:1f.3: kvm assign device
failed ret -22 >" is comming as iommu attach device
fails because of following check .
1094 int iommu_attach_device(struct iommu_domain *domain, struct device
*dev)
1095 {
1096 struct iommu_group *group;
1097 int ret;
1098
1099 group = iommu_group_get(dev);
1100 /* FIXME: Remove this when groups a mandatory for iommu
drivers */
1101 if (group == NULL)
1102 return __iommu_attach_device(domain, dev);
1103
> > root@shining-node:~# ls
> > /sys/bus/pci/devices/\:00\:1f.3/iommu_group/devices/
> > :00:1f.0 :00:1f.2 :00:1f.3 :00:1f.6
> > root@shining-node:~#
> > root@shining-node:~# lspci -v -s :00:1f
> > 00:1f.0 ISA bridge: Intel Corporation C610/X99 series chipset LPC
> > Controller (rev 05)
> > Subsystem: Intel Corporation C610/X99 series chipset LPC Controller
> > Flags: bus master, medium devsel, latency 0, NUMA node 0
> > Capabilities: [e0] Vendor Specific Information: Len=0c
> > Kernel driver in use: lpc_ich
> > Kernel modules: lpc_ich
> >
> > 00:1f.2 SATA controller: Intel Corporation C610/X99 series chipset 6-Port
> > SATA Controller [AHCI mode] (rev 05) (prog-if 01 [AHCI 1.0])
> > Subsystem: Intel Corporation C610/X99 series chipset 6-Port SATA
> Controller
> > [AHCI mode]
> > Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 35, NUMA node 0
> > I/O ports at 3068 [size=8]
> > I/O ports at 3074 [size=4]
> > I/O ports at 3060 [size=8]
> > I/O ports at 3070 [size=4]
> > I/O ports at 3020 [size=32]
> > Memory at 91d2 (32-bit, non-prefetchable) [size=2K]
> > Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > Capabilities: [70] Power Management version 3
> > Capabilities: [a8] SATA HBA v1.0
> > Kernel driver in use: ahci
> >
> > 00:1f.3 SMBus: Intel Corporation C610/X99 series chipset SMBus Controller
> > (rev 05)
> > Subsystem: Intel Corporation C610/X99 series chipset SMBus Controller
> > Flags: medium devsel, IRQ 18, NUMA node 0
> > Memory at 1860 (64-bit, non-prefetchable) [size=4K]
> > I/O ports at 3000 [size=32]
> > Kernel driver in use: pci-stub
[PATCH] dma-debug: hns_enet_drv could use more DMA entries
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
dma_entry_alloc
[1] for (i = 0; i < handle->q_num; i++)
[2] for (i = 0; i < ring->desc_num; i++)
On this Huawei TaiShan 2280 aarch64 server, it has reached the limit
already,
4 (ports) x 16 (handles) x 1024 (rings) = 65536
Signed-off-by: Qian Cai
---
kernel/dma/debug.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 231ca4628062..ae91689cc9ad 100644
--- a/kernel/dma/debug.c
+++ b/kernel/dma/debug.c
@@ -43,8 +43,13 @@
/* allow architectures to override this if absolutely required */
#ifndef PREALLOC_DMA_DEBUG_ENTRIES
+/* amount of DMA mappings on this driver is huge. */
+#ifdef HNS_ENET
+#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 17)
+#else
#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
#endif
+#endif
enum {
dma_debug_single,
--
2.17.2 (Apple Git-113)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 1/4] PCI / ACPI: Identify untrusted PCI devices
On Thu, Nov 29, 2018 at 4:52 PM Mika Westerberg
wrote:
>
> A malicious PCI device may use DMA to attack the system. An external
> Thunderbolt port is a convenient point to attach such a device. The OS
> may use IOMMU to defend against DMA attacks.
>
> Recent BIOSes with Thunderbolt ports mark these externally facing root
> ports with this ACPI _DSD [1]:
>
> Name (_DSD, Package () {
> ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
> Package () {
> Package () {"ExternalFacingPort", 1},
> Package () {"UID", 0 }
> }
> })
>
> If we find such a root port, mark it and all its children as untrusted.
> The rest of the OS may use this information to enable DMA protection
> against malicious devices. For instance the device may be put behind an
> IOMMU to keep it from accessing memory outside of what the driver has
> allocated for it.
>
> While at it, add a comment on top of prp_guids array explaining the
> possible caveat resulting when these GUIDs are treated equivalent.
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
>
> Signed-off-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
> ---
> drivers/acpi/property.c | 11 +++
> drivers/pci/pci-acpi.c | 19 +++
> drivers/pci/probe.c | 15 +++
> include/linux/pci.h | 8
> 4 files changed, 53 insertions(+)
>
> diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> index 8c7c4583b52d..77abe0ec4043 100644
> --- a/drivers/acpi/property.c
> +++ b/drivers/acpi/property.c
> @@ -24,6 +24,14 @@ static int acpi_data_get_property_array(const struct
> acpi_device_data *data,
> acpi_object_type type,
> const union acpi_object **obj);
>
> +/*
> + * The GUIDs here are made equivalent to each other in order to avoid extra
> + * complexity in the properties handling code, with the caveat that the
> + * kernel will accept certain combinations of GUID and properties that are
> + * not defined without a warning. For instance if any of the properties
> + * from different GUID appear in a property list of another, it will be
> + * accepted by the kernel. Firmware validation tools should catch these.
> + */
> static const guid_t prp_guids[] = {
> /* ACPI _DSD device properties GUID:
> daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
> GUID_INIT(0xdaffd814, 0x6eba, 0x4d8c,
> @@ -31,6 +39,9 @@ static const guid_t prp_guids[] = {
> /* Hotplug in D3 GUID: 6211e2c0-58a3-4af3-90e1-927a4e0c55a4 */
> GUID_INIT(0x6211e2c0, 0x58a3, 0x4af3,
> 0x90, 0xe1, 0x92, 0x7a, 0x4e, 0x0c, 0x55, 0xa4),
> + /* External facing port GUID: efcc06cc-73ac-4bc3-bff0-76143807c389 */
> + GUID_INIT(0xefcc06cc, 0x73ac, 0x4bc3,
> + 0xbf, 0xf0, 0x76, 0x14, 0x38, 0x07, 0xc3, 0x89),
> };
>
> static const guid_t ads_guid =
> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> index 921db6f80340..e1949f7efd9c 100644
> --- a/drivers/pci/pci-acpi.c
> +++ b/drivers/pci/pci-acpi.c
> @@ -789,6 +789,24 @@ static void pci_acpi_optimize_delay(struct pci_dev *pdev,
> ACPI_FREE(obj);
> }
>
> +static void pci_acpi_set_untrusted(struct pci_dev *dev)
> +{
> + u8 val;
> +
> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
> + return;
> + if (device_property_read_u8(>dev, "ExternalFacingPort", ))
> + return;
> +
> + /*
> +* These root ports expose PCIe (including DMA) outside of the
> +* system so make sure we treat them and everything behind as
> +* untrusted.
> +*/
> + if (val)
> + dev->untrusted = 1;
> +}
> +
> static void pci_acpi_setup(struct device *dev)
> {
> struct pci_dev *pci_dev = to_pci_dev(dev);
> @@ -798,6 +816,7 @@ static void pci_acpi_setup(struct device *dev)
> return;
>
> pci_acpi_optimize_delay(pci_dev, adev->handle);
> + pci_acpi_set_untrusted(pci_dev);
>
> pci_acpi_add_pm_notifier(adev, pci_dev);
> if (!adev->wakeup.flags.valid)
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index b1c05b5054a0..257b9f6f2ebb 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1378,6 +1378,19 @@ static void set_pcie_thunderbolt(struct pci_dev *dev)
> }
> }
>
> +static void set_pcie_untrusted(struct pci_dev *dev)
> +{
> + struct pci_dev *parent;
> +
> + /*
> +* If the upstream bridge is untrusted we treat this device
> +* untrusted as well.
> +*/
> + parent = pci_upstream_bridge(dev);
> + if (parent && parent->untrusted)
> + dev->untrusted = true;
> +}
> +
> /**
> * pci_ext_cfg_is_aliased - Is ext config space just an alias of std config?
> * @dev: PCI device
> @@ -1638,6 +1651,8 @@ int
Re: remove the ->mapping_error method from dma_map_ops V2
On Thu, Nov 29, 2018 at 10:53:32AM -0800, Linus Torvalds wrote: > Most of the high-performance IO is already using SG lists anyway, no? > Disk/networking/whatever. Networking basically never uses S/G lists. Block I/O mostly uses it, and graphics / media seems to have a fair amount of S/G uses, including very, erm special ones. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: remove the ->mapping_error method from dma_map_ops V2
On Thu, Nov 29, 2018 at 10:31 AM Christoph Hellwig wrote:
>
> > Or, better yet, plan on removing the single-page dma mappign entirely
> > at a later date, and make the issue moot.
>
> What would be the replacement? Build a S/G list for every single page
> mapping? Not sure that would create a lot of happy campers..
It's what we ended up doing with some other cases, and it didn't
really end up hurting as much as I thought it would.
I'm thinking of the vfs functions that end up turning "buf, len" into
struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
and then passing it around as a single-entry iov instead (not even
that - they end up being an iov_iter, which is not just the iov, but
the whole "what _kind_ of iov" indirection)
Maybe a very similar model could be used for just simplifying the core
dma mapping setup: sure, people will want to do single-area dma, but
how bad would it be to just turn them into single-entry SG lists on
stack, and then the dma-maping internally would just always see that?
Most of the high-performance IO is already using SG lists anyway, no?
Disk/networking/whatever.
But just an idea. And the "map_sg()" error handling isn't actually any
better, I think. It returns zero on error, no? So it's not improving
the error handling.
The whole dma-mapping layer seems full of those kinds of "inspired
error handling choices" ;)
Linus
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: remove the ->mapping_error method from dma_map_ops V2
On Thu, Nov 29, 2018 at 09:44:05AM -0800, Linus Torvalds wrote: > No. Really. If there's no iotlb, then you just mark that one page > reserved. It simply doesn't get used. It doesn't mean you suddenly > need a swiotlb. Sure, we could just skip that page entirely based on dma_to_phys. > But whatever. It's independent from the patch series under discussion. > Make dma_mapping_error() at least return a real error (eg -EINVAL, or > whatever is the common error), and we can maybe do this later. Ok, I'll do that. > Or, better yet, plan on removing the single-page dma mappign entirely > at a later date, and make the issue moot. What would be the replacement? Build a S/G list for every single page mapping? Not sure that would create a lot of happy campers.. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: remove the ->mapping_error method from dma_map_ops V2
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote: > > We can. At least in theory. The problem is that depending on the > crazy mapping from physical and kernel virtual address to dma addresses > these might be pages at pretty random places. Look at fun like > arch/x86/pci/sta2x11-fixup.c for how ugly these mappings could look. > > It also means that we might have setup swiotlb on just about every > 32-bit architecture, even if it has no real addressing limit except for > the one we imposed. No. Really. If there's no iotlb, then you just mark that one page reserved. It simply doesn't get used. It doesn't mean you suddenly need a swiotlb. If there *is* a iotlb, none of this should matter, because you'd just never map anything into that page. But whatever. It's independent from the patch series under discussion. Make dma_mapping_error() at least return a real error (eg -EINVAL, or whatever is the common error), and we can maybe do this later. Or, better yet, plan on removing the single-page dma mappign entirely at a later date, and make the issue moot. Linus ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: scatterlist arch cleanups
ping, any comments? On Fri, Nov 09, 2018 at 10:00:06AM +0100, Christoph Hellwig wrote: > Remove leftovers, and switch the default on enabling SG chaining. > ___ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu ---end quoted text--- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On Thu, Nov 29, 2018 at 01:05:23PM +0100, Christian Zigotzky wrote: > I compiled a test kernel from the following Git today. > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4 > > Command: git clone git://git.infradead.org/users/hch/misc.git -b > powerpc-dma.4 a > > Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't > work anymore. What kind of machine is this (and your other one)? Can you send me (or point me to) the .config files? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
> > Please don't apply the new DMA mapping code if you don't be sure if it > > works on all supported PowerPC machines. Is the new DMA mapping code > > really necessary? It's not really nice, to rewrote code if the old code > > works perfect. We must not forget, that we work for the end users. Does > > the end user have advantages with this new code? Is it faster? The old > > code works without any problems. > > There is another service provided to the users as well: new code that is > cleaner and simpler which allows easier bug fixes and new features. > Without being familiar with the DMA mapping code I cannot really say if > that's the case here. Yes, the main point is to move all architecturs to common code for the dma direct mapping code. This means we have one code bases that sees bugs fixed and features introduced the same way for everyone. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On Wed, Nov 28, 2018 at 10:05:19PM +1100, Michael Ellerman wrote: > Is the plan that you take these via the dma-mapping tree or that they go > via powerpc? In principle either way is fine with me. If it goes through the powerpc tree we might run into a few minor conflicts with the dma-mapping tree depending on how some of the current discussions go. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: remove the ->mapping_error method from dma_map_ops V2
On Wed, Nov 28, 2018 at 11:19:15AM -0800, Linus Torvalds wrote: > Let me just paste it back in here: > > "Which is what we ALREADY do for these exact reasons. If the DMA > mappings means that you'd need to add one more page to that list of > reserved pages, then so be it." > > So no, I'm not at all confused. > > Let me re-iterate: the argument that all addresses have to be dma'able is > garbage. > > *Exactly* as with kmalloc and limited virtual addresses, we can limit > physical addresses. We can. At least in theory. The problem is that depending on the crazy mapping from physical and kernel virtual address to dma addresses these might be pages at pretty random places. Look at fun like arch/x86/pci/sta2x11-fixup.c for how ugly these mappings could look. It also means that we might have setup swiotlb on just about every 32-bit architecture, even if it has no real addressing limit except for the one we imposed. I don't really see how this is a win for us just to be able to report more detailed error codes, which would be nice to have, but the lack of which hasn't really harmed us. So as far as I'm concerned I'd go either with the series that we are discussing here, or change the map_page method to return an errno and the dma_addr_t in the argument. As Davem pointed out that can lead to less optimal code, but it would still be better than the indirect call we have. But then again I think the series as posted here might and up much simpler and good enough without opening up this rathole. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 1/4] PCI / ACPI: Identify untrusted PCI devices
A malicious PCI device may use DMA to attack the system. An external
Thunderbolt port is a convenient point to attach such a device. The OS
may use IOMMU to defend against DMA attacks.
Recent BIOSes with Thunderbolt ports mark these externally facing root
ports with this ACPI _DSD [1]:
Name (_DSD, Package () {
ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
Package () {
Package () {"ExternalFacingPort", 1},
Package () {"UID", 0 }
}
})
If we find such a root port, mark it and all its children as untrusted.
The rest of the OS may use this information to enable DMA protection
against malicious devices. For instance the device may be put behind an
IOMMU to keep it from accessing memory outside of what the driver has
allocated for it.
While at it, add a comment on top of prp_guids array explaining the
possible caveat resulting when these GUIDs are treated equivalent.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
Signed-off-by: Mika Westerberg
---
drivers/acpi/property.c | 11 +++
drivers/pci/pci-acpi.c | 19 +++
drivers/pci/probe.c | 15 +++
include/linux/pci.h | 8
4 files changed, 53 insertions(+)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 8c7c4583b52d..77abe0ec4043 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -24,6 +24,14 @@ static int acpi_data_get_property_array(const struct
acpi_device_data *data,
acpi_object_type type,
const union acpi_object **obj);
+/*
+ * The GUIDs here are made equivalent to each other in order to avoid extra
+ * complexity in the properties handling code, with the caveat that the
+ * kernel will accept certain combinations of GUID and properties that are
+ * not defined without a warning. For instance if any of the properties
+ * from different GUID appear in a property list of another, it will be
+ * accepted by the kernel. Firmware validation tools should catch these.
+ */
static const guid_t prp_guids[] = {
/* ACPI _DSD device properties GUID:
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
GUID_INIT(0xdaffd814, 0x6eba, 0x4d8c,
@@ -31,6 +39,9 @@ static const guid_t prp_guids[] = {
/* Hotplug in D3 GUID: 6211e2c0-58a3-4af3-90e1-927a4e0c55a4 */
GUID_INIT(0x6211e2c0, 0x58a3, 0x4af3,
0x90, 0xe1, 0x92, 0x7a, 0x4e, 0x0c, 0x55, 0xa4),
+ /* External facing port GUID: efcc06cc-73ac-4bc3-bff0-76143807c389 */
+ GUID_INIT(0xefcc06cc, 0x73ac, 0x4bc3,
+ 0xbf, 0xf0, 0x76, 0x14, 0x38, 0x07, 0xc3, 0x89),
};
static const guid_t ads_guid =
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 921db6f80340..e1949f7efd9c 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -789,6 +789,24 @@ static void pci_acpi_optimize_delay(struct pci_dev *pdev,
ACPI_FREE(obj);
}
+static void pci_acpi_set_untrusted(struct pci_dev *dev)
+{
+ u8 val;
+
+ if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
+ return;
+ if (device_property_read_u8(>dev, "ExternalFacingPort", ))
+ return;
+
+ /*
+* These root ports expose PCIe (including DMA) outside of the
+* system so make sure we treat them and everything behind as
+* untrusted.
+*/
+ if (val)
+ dev->untrusted = 1;
+}
+
static void pci_acpi_setup(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
@@ -798,6 +816,7 @@ static void pci_acpi_setup(struct device *dev)
return;
pci_acpi_optimize_delay(pci_dev, adev->handle);
+ pci_acpi_set_untrusted(pci_dev);
pci_acpi_add_pm_notifier(adev, pci_dev);
if (!adev->wakeup.flags.valid)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b1c05b5054a0..257b9f6f2ebb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1378,6 +1378,19 @@ static void set_pcie_thunderbolt(struct pci_dev *dev)
}
}
+static void set_pcie_untrusted(struct pci_dev *dev)
+{
+ struct pci_dev *parent;
+
+ /*
+* If the upstream bridge is untrusted we treat this device
+* untrusted as well.
+*/
+ parent = pci_upstream_bridge(dev);
+ if (parent && parent->untrusted)
+ dev->untrusted = true;
+}
+
/**
* pci_ext_cfg_is_aliased - Is ext config space just an alias of std config?
* @dev: PCI device
@@ -1638,6 +1651,8 @@ int pci_setup_device(struct pci_dev *dev)
/* Need to have dev->cfg_size ready */
set_pcie_thunderbolt(dev);
+ set_pcie_untrusted(dev);
+
/* "Unknown power state" */
dev->current_state = PCI_UNKNOWN;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 11c71c4ecf75..c786a2f27bee 100644
---
[PATCH v3 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection
Recent systems with Thunderbolt ports may be utilizing IOMMU to prevent DMA attacks. This is different from the previous security level based scheme because the connected device cannot access system memory outside of the regions allocated for it by the driver. When enabled the BIOS makes sure no device can do DMA outside of RMRR (Reserved Memory Region Record) regions. This means that during OS boot, before it enables IOMMU, none of the connected devices can bypass DMA protection for instance by overwriting the data structures used by the IOMMU. The BIOS communicates support for this to the OS by setting a new bit in ACPI DMAR table [1]. Because these systems utilize an IOMMU to block possible DMA attacks, typically (but not always) the Thunderbolt security level is set to "none" which means that all PCIe devices are immediately usable. This also means that Linux needs to follow Windows 10 and enable IOMMU automatically when running on such system otherwise connected devices can read/write system memory pretty much without any restrictions. Since there is a way to identify PCIe root ports that are "external facing" we can put all internal devices to pass through (identity mapping) mode and only external devices need to go through full IOMMU mappings. We add a new flag "untrusted" that is supposed to cover various PCIe devices that may be used to conduct DMA attacks. We also make sure PCIe ATS (Address Translation Service) is not enabled for devices flagged as untrusted because it could be used to bypass IOMMU completely as explained in the changelog of patch 3/4. Finally we expose this information to userspace so tools such as bolt can do more accurate decision whether or not authorize the connected device. [1] https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf Previous version of the patch series can be found here: v2: https://lkml.org/lkml/2018/11/26/638 v1: https://www.spinics.net/lists/linux-pci/msg77751.html Changes from v2: * Rename the flag to "untrusted" * Simplify setting the flag for root ports * Dropped loop in set_pcie_untrusted() * Add comment on top of prp_guids explaining the possible caveat resulting when the new GUIDs are treated as equivalent * Updated changelogs according to feedback Changes from v1: * Reword Documentation/admin-guide/thunderbolt.rst to make the feature time frame/platform oriented as there will be systems shipping with Linux installed by default. * Rename the flag is_external to is_untrusted so that we could use the same flag to cover all kinds of "untrusted" PCI devices, not just Thunderbolt connected devices. I still parse the _DSD in PCI/ACPI core because that's where we currently handle "HotPlugSupportInD3" as well. Also updated comments in patch [1/4]. * Added tags from Ashok, Joerg and Yehezkel. I'm assuming they still apply because I did not change the code with the exception of few comments and rename of the flag. Let me know if that's not the case anymore. Lu Baolu (1): iommu/vt-d: Force IOMMU on for platform opt in hint Mika Westerberg (3): PCI / ACPI: Identify untrusted PCI devices iommu/vt-d: Do not enable ATS for untrusted devices thunderbolt: Export IOMMU based DMA protection support to userspace .../ABI/testing/sysfs-bus-thunderbolt | 9 +++ Documentation/admin-guide/thunderbolt.rst | 20 +++ drivers/acpi/property.c | 11 drivers/iommu/dmar.c | 25 + drivers/iommu/intel-iommu.c | 56 ++- drivers/pci/pci-acpi.c| 19 +++ drivers/pci/probe.c | 15 + drivers/thunderbolt/domain.c | 17 ++ include/linux/dmar.h | 8 +++ include/linux/pci.h | 8 +++ 10 files changed, 185 insertions(+), 3 deletions(-) -- 2.19.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace
Recent systems with Thunderbolt ports may support IOMMU natively. In
practice this means that Thunderbolt connected devices are placed behind
an IOMMU during the whole time it is connected (including during boot)
making Thunderbolt security levels redundant. This is called Kernel DMA
protection [1] by Microsoft.
Some of these systems still have Thunderbolt security level set to
"user" in order to support OS downgrade (the older version of the OS
might not support IOMMU based DMA protection so connecting a device
still relies on user approval).
Export this information to userspace by introducing a new sysfs
attribute (iommu_dma_protection). Based on it userspace tools can make
more accurate decision whether or not authorize the connected device.
In addition update Thunderbolt documentation regarding IOMMU based DMA
protection.
[1]
https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
Signed-off-by: Mika Westerberg
Reviewed-by: Yehezkel Bernat
---
.../ABI/testing/sysfs-bus-thunderbolt | 9 +
Documentation/admin-guide/thunderbolt.rst | 20 +++
drivers/thunderbolt/domain.c | 17
3 files changed, 46 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt
b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index 151584a1f950..b21fba14689b 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -21,6 +21,15 @@ Description: Holds a comma separated list of device
unique_ids that
If a device is authorized automatically during boot its
boot attribute is set to 1.
+What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
+Date: Mar 2019
+KernelVersion: 4.21
+Contact: thunderbolt-softw...@lists.01.org
+Description: This attribute tells whether the system uses IOMMU
+ for DMA protection. Value of 1 means IOMMU is used 0 means
+ it is not (DMA protection is solely based on Thunderbolt
+ security levels).
+
What: /sys/bus/thunderbolt/devices/.../domainX/security
Date: Sep 2017
KernelVersion: 4.13
diff --git a/Documentation/admin-guide/thunderbolt.rst
b/Documentation/admin-guide/thunderbolt.rst
index 35fccba6a9a6..898ad78f3cc7 100644
--- a/Documentation/admin-guide/thunderbolt.rst
+++ b/Documentation/admin-guide/thunderbolt.rst
@@ -133,6 +133,26 @@ If the user still wants to connect the device they can
either approve
the device without a key or write a new key and write 1 to the
``authorized`` file to get the new key stored on the device NVM.
+DMA protection utilizing IOMMU
+--
+Recent systems from 2018 and forward with Thunderbolt ports may natively
+support IOMMU. This means that Thunderbolt security is handled by an IOMMU
+so connected devices cannot access memory regions outside of what is
+allocated for them by drivers. When Linux is running on such system it
+automatically enables IOMMU if not enabled by the user already. These
+systems can be identified by reading ``1`` from
+``/sys/bus/thunderbolt/devices/domainX/iommu_dma_protection`` attribute.
+
+The driver does not do anything special in this case but because DMA
+protection is handled by the IOMMU, security levels (if set) are
+redundant. For this reason some systems ship with security level set to
+``none``. Other systems have security level set to ``user`` in order to
+support downgrade to older OS, so users who want to automatically
+authorize devices when IOMMU DMA protection is enabled can use the
+following ``udev`` rule::
+
+ ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1",
ATTR{authorized}=="0", ATTR{authorized}="1"
+
Upgrading NVM on Thunderbolt device or host
---
Since most of the functionality is handled in firmware running on a
diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
index 93e562f18d40..7416bdbd8576 100644
--- a/drivers/thunderbolt/domain.c
+++ b/drivers/thunderbolt/domain.c
@@ -7,7 +7,9 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
@@ -236,6 +238,20 @@ static ssize_t boot_acl_store(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_RW(boot_acl);
+static ssize_t iommu_dma_protection_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ /*
+* Kernel DMA protection is a feature where Thunderbolt security is
+* handled natively using IOMMU. It is enabled when IOMMU is
+* enabled and ACPI DMAR table has DMAR_PLATFORM_OPT_IN set.
+*/
+ return sprintf(buf, "%d\n",
+ iommu_present(_bus_type) && dmar_platform_optin());
+}
+static
[PATCH v3 2/4] iommu/vt-d: Force IOMMU on for platform opt in hint
From: Lu Baolu
Intel VT-d spec added a new DMA_CTRL_PLATFORM_OPT_IN_FLAG flag in DMAR
ACPI table [1] for BIOS to report compliance about platform initiated
DMA restricted to RMRR ranges when transferring control to the OS. This
means that during OS boot, before it enables IOMMU none of the connected
devices can bypass DMA protection for instance by overwriting the data
structures used by the IOMMU. The OS also treats this as a hint that the
IOMMU should be enabled to prevent DMA attacks from possible malicious
devices.
A use of this flag is Kernel DMA protection for Thunderbolt [2] which in
practice means that IOMMU should be enabled for PCIe devices connected
to the Thunderbolt ports. With IOMMU enabled for these devices, all DMA
operations are limited in the range reserved for it, thus the DMA
attacks are prevented. All these devices are enumerated in the PCI/PCIe
module and marked with an untrusted flag.
This forces IOMMU to be enabled if DMA_CTRL_PLATFORM_OPT_IN_FLAG is set
in DMAR ACPI table and there are PCIe devices marked as untrusted in the
system. This can be turned off by adding "intel_iommu=off" in the kernel
command line, if any problems are found.
[1]
https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf
[2]
https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Signed-off-by: Mika Westerberg
Reviewed-by: Ashok Raj
Reviewed-by: Joerg Roedel
Acked-by: Joerg Roedel
---
drivers/iommu/dmar.c| 25 +
drivers/iommu/intel-iommu.c | 53 +++--
include/linux/dmar.h| 8 ++
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index d9c748b6f9e4..1edf2a251336 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -2042,3 +2042,28 @@ int dmar_device_remove(acpi_handle handle)
{
return dmar_device_hotplug(handle, false);
}
+
+/*
+ * dmar_platform_optin - Is %DMA_CTRL_PLATFORM_OPT_IN_FLAG set in DMAR table
+ *
+ * Returns true if the platform has %DMA_CTRL_PLATFORM_OPT_IN_FLAG set in
+ * the ACPI DMAR table. This means that the platform boot firmware has made
+ * sure no device can issue DMA outside of RMRR regions.
+ */
+bool dmar_platform_optin(void)
+{
+ struct acpi_table_dmar *dmar;
+ acpi_status status;
+ bool ret;
+
+ status = acpi_get_table(ACPI_SIG_DMAR, 0,
+ (struct acpi_table_header **));
+ if (ACPI_FAILURE(status))
+ return false;
+
+ ret = !!(dmar->flags & DMAR_PLATFORM_OPT_IN);
+ acpi_put_table((struct acpi_table_header *)dmar);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dmar_platform_optin);
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 41a4b8808802..30e8584137f5 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -184,6 +184,7 @@ static int rwbf_quirk;
*/
static int force_on = 0;
int intel_iommu_tboot_noforce;
+static int no_platform_optin;
#define ROOT_ENTRY_NR (VTD_PAGE_SIZE/sizeof(struct root_entry))
@@ -503,6 +504,7 @@ static int __init intel_iommu_setup(char *str)
pr_info("IOMMU enabled\n");
} else if (!strncmp(str, "off", 3)) {
dmar_disabled = 1;
+ no_platform_optin = 1;
pr_info("IOMMU disabled\n");
} else if (!strncmp(str, "igfx_off", 8)) {
dmar_map_gfx = 0;
@@ -2895,6 +2897,13 @@ static int iommu_should_identity_map(struct device *dev,
int startup)
if (device_is_rmrr_locked(dev))
return 0;
+ /*
+* Prevent any device marked as untrusted from getting
+* placed into the statically identity mapping domain.
+*/
+ if (pdev->untrusted)
+ return 0;
+
if ((iommu_identity_mapping & IDENTMAP_AZALIA) &&
IS_AZALIA(pdev))
return 1;
@@ -4728,14 +4737,54 @@ const struct attribute_group *intel_iommu_groups[] = {
NULL,
};
+static int __init platform_optin_force_iommu(void)
+{
+ struct pci_dev *pdev = NULL;
+ bool has_untrusted_dev = false;
+
+ if (!dmar_platform_optin() || no_platform_optin)
+ return 0;
+
+ for_each_pci_dev(pdev) {
+ if (pdev->untrusted) {
+ has_untrusted_dev = true;
+ break;
+ }
+ }
+
+ if (!has_untrusted_dev)
+ return 0;
+
+ if (no_iommu || dmar_disabled)
+ pr_info("Intel-IOMMU force enabled due to platform opt in\n");
+
+ /*
+* If Intel-IOMMU is disabled by default, we will apply identity
+* map for all devices except those
Re: use generic DMA mapping code in powerpc V4
On 29 November 2018 at 1:05PM, Christian Zigotzky wrote: On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Christoph Hellwig writes: Any comments? I'd like to at least get the ball moving on the easy bits. Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. There's not much we can do about that, but I'll just try and test it on everything I can find. Is the plan that you take these via the dma-mapping tree or that they go via powerpc? cheers Hi All, I compiled a test kernel from the following Git today. http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4 Command: git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.4 a Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't work anymore. [ 367.627623] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627631] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627639] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627647] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627655] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627686] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628418] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628505] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628592] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629324] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629417] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629495] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629589] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 430.424732]pasemi_mac: rcmdsta error: 0x04ef3001 I tested this kernel with the Nemo board (CPU: PWRficient PA6T-1682M). The PASEMI ethernet works with the RC4 of kernel 4.20. Cheers, Christian Hi All, I tested this kernel on my NXP QorIQ P5020 board. U-Boot loads the dtb file and the kernel and after that the booting stops. This board works with the RC4 of kernel 4.20. Please test this kernel on your NXP and PASEMI boards. Thanks, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v18 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops
On Wed, Nov 28, 2018 at 10:07 PM Robin Murphy wrote:
>
> On 28/11/2018 16:24, Stephen Boyd wrote:
> > Quoting Vivek Gautam (2018-11-27 02:11:41)
> >> @@ -1966,6 +1970,23 @@ static const struct of_device_id
> >> arm_smmu_of_match[] = {
> >> };
> >> MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
> >>
> >> +static void arm_smmu_fill_clk_data(struct arm_smmu_device *smmu,
> >> + const char * const *clks)
> >> +{
> >> + int i;
> >> +
> >> + if (smmu->num_clks < 1)
> >> + return;
> >> +
> >> + smmu->clks = devm_kcalloc(smmu->dev, smmu->num_clks,
> >> + sizeof(*smmu->clks), GFP_KERNEL);
> >> + if (!smmu->clks)
> >> + return;
> >> +
> >> + for (i = 0; i < smmu->num_clks; i++)
> >> + smmu->clks[i].id = clks[i];
> >
> > Is this clk_bulk_get_all()?
>From what I remember, and now I could go back to v7 and check [1], we parked
clk_bulk_get out of OF's sole purview as we also have
arm_smmu_device_acpi_probe() besides arm_smmu_device_dt_probe().
arm_smmu_device_dt_probe() could get the clocks from dt and fill in
the clock bulk data, and
similarly, arm_smmu_device_acpi_probe() could fill the clock bulk data
by getting it from ACPI.
clk_bulk_get_all() seems like going only the OF way.
Is there another way here to have something common between ACPI
and OF, and then do the clk_bulk_get?
[1] https://lore.kernel.org/patchwork/patch/881365/
Thanks & regards
Vivek
>
> Ooh, did that finally get merged while we weren't looking? Great!
>
> Much as I don't want to drag this series out to a v19, it *would* be
> neat if we no longer need to open-code that bit...
>
> Robin.
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 07/17] debugobjects: Move printk out of db lock critical sections
On Mon 2018-11-26 13:57:09, Sergey Senozhatsky wrote: > On (11/23/18 12:48), Petr Mladek wrote: > [..] > > > This should make serial consoles re-entrant. > > > So printk->console_driver_write() hopefully will not deadlock. > > > > Is the re-entrance safe? Some risk might be acceptable in Oops/panic > > situations. It is much less acceptable for random warnings. > > Good question. > > But what's the alternative? A deadlock in a serial console driver; such > that even panic() is not guaranteed to make through it (at least of now). > debug objects are used from the code which cannot re-entrant console > drivers. > > bust_spinlock is called from various paths, not only panic. > git grep bust_spinlocks | wc -l > 62 bust_spinlocks() is followed by die() in several situations. The rests seems to be Oops situations where we an invalid address is being accessed. There is a nontrivial chance that the system would die anyway. Now, if I look into Documentation/core-api/debug-objects.rst, the API is used to detect: - Activation of uninitialized objects - Initialization of active objects - Usage of freed/destroyed objects Of course, all the above situations might lead to the system crash. But even in the worst case, use-after-free, there is a non-trivial chance that the data still would be valid and the system would survive. There might be many other warnings of the same severity. > So we already switch to re-entrant consoles (and accept the risks) in > mm/fault.c, kernel/traps.c and so on. Which, I guess, makes us a little > more confident, faults/traps happen often enough. Where is the border line, please? Do we want to have the kernel sources full of bust_spinlocks() callers? > It seems, that, more or less, serial consoles are ready to handle it. > UART consoles in ->write() callbacks just do a bunch of writel() [for > every char + \r\n]. But oops_in_progress does not affect only serial (UART) consoles. We want safe lockless consoles. We do not want to run a most-of-the-time-safe code too often. BTW: I have heard that someone from the RT people is working on a big printk() rewrite. One part is a lockless buffer. Another part should be a different handling of safe (lockless) and more complicated consoles. It was presented on some recent conference (I forgot which one). I do not know any details. But the first version should be sent in a near future. Best Regards, Petr ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Christoph Hellwig writes: Any comments? I'd like to at least get the ball moving on the easy bits. Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. There's not much we can do about that, but I'll just try and test it on everything I can find. Is the plan that you take these via the dma-mapping tree or that they go via powerpc? cheers Hi All, I compiled a test kernel from the following Git today. http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4 Command: git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.4 a Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't work anymore. [ 367.627623] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627631] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627639] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627647] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627655] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627686] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628418] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628505] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628592] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629324] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629417] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629495] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629589] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 430.424732]pasemi_mac: rcmdsta error: 0x04ef3001 I tested this kernel with the Nemo board (CPU: PWRficient PA6T-1682M). The PASEMI ethernet works with the RC4 of kernel 4.20. Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/2] iommu/ipmmu-vmsa: add an array of slave devices whitelist
On Wed, Nov 28, 2018 at 09:23:36AM +, Yoshihiro Shimoda wrote: > To avoid adding copy and pasted strcmp codes in the future, > this patch adds an array "rcar_gen3_slave_whitelist" to check > whether the device can work with the IPMMU or not. > > Signed-off-by: Yoshihiro Shimoda > Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] iommu/ipmmu-vmsa: Modify ipmmu_slave_whitelist() to check SoC revisions
On Wed, Nov 28, 2018 at 09:23:36AM +, Yoshihiro Shimoda wrote: > Some R-Car Gen3 SoCs has hardware restrictions on the IPMMU. So, > to check whether this R-Car Gen3 SoC can use the IPMMU correctly, > this patch modifies the ipmmu_slave_whitelist(). > > Signed-off-by: Yoshihiro Shimoda > Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 3.18 1/6] iommu/ipmmu-vmsa: Fix crash on early domain free
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual address
0038
...
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
Fix this by checking if the domain's context already exists, before
trying to destroy it.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 7dab5cbcc775..47e8db51288b 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -383,6 +383,9 @@ static int ipmmu_domain_init_context(struct
ipmmu_vmsa_domain *domain)
static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
{
+ if (!domain->mmu)
+ return;
+
/*
* Disable the context. Flush the TLB as required when modifying the
* context registers.
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.9 04/18] iommu/ipmmu-vmsa: Fix crash on early domain free
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual address
0038
...
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
Fix this by checking if the domain's context already exists, before
trying to destroy it.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 85b5e75c7faa..3d2e9ca78f02 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -372,6 +372,9 @@ static int ipmmu_domain_init_context(struct
ipmmu_vmsa_domain *domain)
static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
{
+ if (!domain->mmu)
+ return;
+
/*
* Disable the context. Flush the TLB as required when modifying the
* context registers.
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.4 01/13] iommu/vt-d: Fix NULL pointer dereference in prq_event_thread()
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Fixes: a222a7f0bb6c9 'iommu/vt-d: Implement page request handling'
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 10068a481e22..cbde03e509c1 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -558,7 +558,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
pr_err("%s: Page request without PASID: %08llx
%08llx\n",
iommu->name, ((unsigned long long *)req)[0],
((unsigned long long *)req)[1]);
- goto bad_req;
+ goto no_pasid;
}
if (!svm || svm->pasid != req->pasid) {
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.4 02/13] iommu/ipmmu-vmsa: Fix crash on early domain free
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual address
0038
...
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
Fix this by checking if the domain's context already exists, before
trying to destroy it.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 624e7ff76166..9101be1a6b59 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -372,6 +372,9 @@ static int ipmmu_domain_init_context(struct
ipmmu_vmsa_domain *domain)
static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
{
+ if (!domain->mmu)
+ return;
+
/*
* Disable the context. Flush the TLB as required when modifying the
* context registers.
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.4 12/13] iommu/vt-d: Use memunmap to free memremap
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 49b266433f4c..7feaa82f8c7c 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2977,7 +2977,7 @@ static int copy_context_table(struct intel_iommu *iommu,
}
if (old_ce)
- iounmap(old_ce);
+ memunmap(old_ce);
ret = 0;
if (devfn < 0x80)
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.9 16/18] iommu/vt-d: Use memunmap to free memremap
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 2558a381e118..f8c8537f0587 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3054,7 +3054,7 @@ static int copy_context_table(struct intel_iommu *iommu,
}
if (old_ce)
- iounmap(old_ce);
+ memunmap(old_ce);
ret = 0;
if (devfn < 0x80)
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.9 02/18] iommu/vt-d: Fix NULL pointer dereference in prq_event_thread()
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Fixes: a222a7f0bb6c9 'iommu/vt-d: Implement page request handling'
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index f846f0140a9d..7dc2f8d415b6 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -558,7 +558,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
pr_err("%s: Page request without PASID: %08llx
%08llx\n",
iommu->name, ((unsigned long long *)req)[0],
((unsigned long long *)req)[1]);
- goto bad_req;
+ goto no_pasid;
}
if (!svm || svm->pasid != req->pasid) {
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.14 02/35] iommu/vt-d: Fix NULL pointer dereference in prq_event_thread()
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Fixes: a222a7f0bb6c9 'iommu/vt-d: Implement page request handling'
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index d7def26ccf79..f5573bb9f450 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -589,7 +589,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
pr_err("%s: Page request without PASID: %08llx
%08llx\n",
iommu->name, ((unsigned long long *)req)[0],
((unsigned long long *)req)[1]);
- goto bad_req;
+ goto no_pasid;
}
if (!svm || svm->pasid != req->pasid) {
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.14 10/35] amd/iommu: Fix Guest Virtual APIC Log Tail Address Register
From: Filippo Sironi
[ Upstream commit ab99be4683d9db33b100497d463274ebd23bd67e ]
This register should have been programmed with the physical address
of the memory location containing the shadow tail pointer for
the guest virtual APIC log instead of the base address.
Fixes: 8bda0cfbdc1a ('iommu/amd: Detect and initialize guest vAPIC log')
Signed-off-by: Filippo Sironi
Signed-off-by: Wei Wang
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/amd_iommu_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6fe2d0346073..b97984a5ddad 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -796,7 +796,8 @@ static int iommu_init_ga_log(struct amd_iommu *iommu)
entry = iommu_virt_to_phys(iommu->ga_log) | GA_LOG_SIZE_512;
memcpy_toio(iommu->mmio_base + MMIO_GA_LOG_BASE_OFFSET,
, sizeof(entry));
- entry = (iommu_virt_to_phys(iommu->ga_log) & 0xFULL) &
~7ULL;
+ entry = (iommu_virt_to_phys(iommu->ga_log_tail) &
+(BIT_ULL(52)-1)) & ~7ULL;
memcpy_toio(iommu->mmio_base + MMIO_GA_LOG_TAIL_OFFSET,
, sizeof(entry));
writel(0x00, iommu->mmio_base + MMIO_GA_HEAD_OFFSET);
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.14 27/35] iommu/vt-d: Use memunmap to free memremap
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index aaf3fed97477..e86c1c8ec7f6 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3086,7 +3086,7 @@ static int copy_context_table(struct intel_iommu *iommu,
}
if (old_ce)
- iounmap(old_ce);
+ memunmap(old_ce);
ret = 0;
if (devfn < 0x80)
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.19 56/68] iommu/vt-d: Use memunmap to free memremap
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index bedc801b06a0..a76c47f20587 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3100,7 +3100,7 @@ static int copy_context_table(struct intel_iommu *iommu,
}
if (old_ce)
- iounmap(old_ce);
+ memunmap(old_ce);
ret = 0;
if (devfn < 0x80)
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.19 08/68] iommu/ipmmu-vmsa: Fix crash on early domain free
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual address
0038
...
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
Fix this by checking if the domain's context already exists, before
trying to destroy it.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 22b94f8a9a04..d8598e44e381 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -501,6 +501,9 @@ static int ipmmu_domain_init_context(struct
ipmmu_vmsa_domain *domain)
static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
{
+ if (!domain->mmu)
+ return;
+
/*
* Disable the context. Flush the TLB as required when modifying the
* context registers.
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.19 16/68] amd/iommu: Fix Guest Virtual APIC Log Tail Address Register
From: Filippo Sironi
[ Upstream commit ab99be4683d9db33b100497d463274ebd23bd67e ]
This register should have been programmed with the physical address
of the memory location containing the shadow tail pointer for
the guest virtual APIC log instead of the base address.
Fixes: 8bda0cfbdc1a ('iommu/amd: Detect and initialize guest vAPIC log')
Signed-off-by: Filippo Sironi
Signed-off-by: Wei Wang
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/amd_iommu_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 84b3e4445d46..e062ab9687c7 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -797,7 +797,8 @@ static int iommu_init_ga_log(struct amd_iommu *iommu)
entry = iommu_virt_to_phys(iommu->ga_log) | GA_LOG_SIZE_512;
memcpy_toio(iommu->mmio_base + MMIO_GA_LOG_BASE_OFFSET,
, sizeof(entry));
- entry = (iommu_virt_to_phys(iommu->ga_log) & 0xFULL) &
~7ULL;
+ entry = (iommu_virt_to_phys(iommu->ga_log_tail) &
+(BIT_ULL(52)-1)) & ~7ULL;
memcpy_toio(iommu->mmio_base + MMIO_GA_LOG_TAIL_OFFSET,
, sizeof(entry));
writel(0x00, iommu->mmio_base + MMIO_GA_HEAD_OFFSET);
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.14 04/35] iommu/ipmmu-vmsa: Fix crash on early domain free
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iommu: Failed to add device ee30.sata to group 0: -22
Unable to handle kernel NULL pointer dereference at virtual address
0038
...
Call trace:
ipmmu_domain_free+0x1c/0xa0
iommu_group_release+0x48/0x68
kobject_put+0x74/0xe8
kobject_del.part.0+0x3c/0x50
kobject_put+0x60/0xe8
iommu_group_get_for_dev+0xa8/0x1f0
ipmmu_add_device+0x1c/0x40
of_iommu_configure+0x118/0x190
Fix this by checking if the domain's context already exists, before
trying to destroy it.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 5d0ba5f644c4..777aff1f549f 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -424,6 +424,9 @@ static int ipmmu_domain_init_context(struct
ipmmu_vmsa_domain *domain)
static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
{
+ if (!domain->mmu)
+ return;
+
/*
* Disable the context. Flush the TLB as required when modifying the
* context registers.
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH AUTOSEL 4.19 05/68] iommu/vt-d: Fix NULL pointer dereference in prq_event_thread()
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu Baolu
Fixes: a222a7f0bb6c9 'iommu/vt-d: Implement page request handling'
Signed-off-by: Joerg Roedel
Signed-off-by: Sasha Levin
---
drivers/iommu/intel-svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 4a03e5090952..188f4eaed6e5 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -596,7 +596,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
pr_err("%s: Page request without PASID: %08llx
%08llx\n",
iommu->name, ((unsigned long long *)req)[0],
((unsigned long long *)req)[1]);
- goto bad_req;
+ goto no_pasid;
}
if (!svm || svm->pasid != req->pasid) {
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
