On Fri, May 15, 2020 at 12:44:00PM +0200, Jean-Philippe Brucker wrote:
> The pci_ats_supported() function checks if a device supports ATS and is
> allowed to use it. In addition to checking that the device has an ATS
> capability and that the global pci=noats is not set
> (pci_ats_disabled()), it
Hi,
On 2020/5/15 17:59, Joerg Roedel wrote:
On Thu, May 14, 2020 at 11:12:52PM +, Prakhya, Sai Praneeth wrote:
+static int is_driver_bound(struct device *dev, void *not_used)
+{
+ int ret = 0;
+
+ device_lock(dev);
+ if (device_is_bound(dev))
+ ret = 1;
+
On Fri, May 15, 2020 at 02:01:50PM +0200, Joerg Roedel wrote:
> On Fri, May 15, 2020 at 12:44:00PM +0200, Jean-Philippe Brucker wrote:
> > The pci_ats_supported() function checks if a device supports ATS and is
> > allowed to use it. In addition to checking that the device has an ATS
> >
On Fri, May 15, 2020 at 09:51:03PM +0800, Lu Baolu wrote:
> On 2020/5/15 17:45, Joerg Roedel wrote:
> > struct iommu_domain *iommu_get_dma_domain(struct device *dev)
> > {
> > - return dev->iommu_group->default_domain;
> > + struct iommu_domain *domain = dev->iommu_group->default_domain;
>
On Fri, May 15, 2020 at 02:11:24PM +0200, Jean-Philippe Brucker wrote:
> On Fri, May 15, 2020 at 02:01:50PM +0200, Joerg Roedel wrote:
> > Hmm, but per patch 1, pci_ats_supported() does not check
> > pci_ats_disabled(), or do I miss something?
>
> The commit message isn't clear. pci_ats_init()
Hi Joerg,
On 2020/5/15 17:45, Joerg Roedel wrote:
From: Joerg Roedel
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
But this
Hi Jean-Philippe,
thanks for doing this!
On Fri, May 15, 2020 at 12:43:59PM +0200, Jean-Philippe Brucker wrote:
> Add pci_ats_supported(), which checks whether a device has an ATS
> capability, and whether it is trusted. A device is untrusted if it is
> plugged into an external-facing port such
On 2020-05-15 09:19, Song Bao Hua wrote:
[ snip... nice analysis, but ultimately it's still "doing stuff has more
overhead than not doing stuff" ]
I am thinking several possible ways on decreasing or removing the latency of DMA
map/unmap for every single DMA transfer. Meanwhile, "non-strict"
On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
>> Meanwhile, for the safety of buffers, lower-layer drivers need to make
>> certain the buffers have already been unmapped in iommu before those buffers
>> go back to buddy for other users.
>
> That sounds like it would only have
On 2020-05-15 10:45, Joerg Roedel wrote:
From: Joerg Roedel
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
But this needs
Can you please lift the untrusted flag into struct device? It really
isn't a PCI specific concept, and we should not have code poking into
pci_dev all over the iommu code.
___
iommu mailing list
iommu@lists.linux-foundation.org
On Fri, May 15, 2020 at 12:39:14AM -0700, Tian, Kevin wrote:
> Hi, Alex,
>
> When working on an updated version Yi and I found an design open
> which needs your guidance.
>
> In concept nested translation can be incarnated as one GPA->HPA page
> table and multiple GVA->GPA page tables per VM. It
On Fri, 15 May 2020 07:39:14 +
"Tian, Kevin" wrote:
> Hi, Alex,
>
> When working on an updated version Yi and I found an design open
> which needs your guidance.
>
> In concept nested translation can be incarnated as one GPA->HPA page
> table and multiple GVA->GPA page tables per VM. It
On Fri, May 15, 2020 at 05:28:53PM +0100, Robin Murphy wrote:
> On 2020-05-15 17:14, Joerg Roedel wrote:
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index ba128d1cdaee..403fda04ea98 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@
On Fri, May 15, 2020 at 08:55:42PM +0800, Lu Baolu wrote:
> It seems that we can do like this:
>
> [1] mutex_lock(>lock)
> [2] for_each_group_device(device_lock())
> [3] if (for_each_group_device(!device_is_bound()))
> change_default_domain()
> [4]
Hi Christoph
On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote:
> Can you please lift the untrusted flag into struct device? It really
> isn't a PCI specific concept, and we should not have code poking into
> pci_dev all over the iommu code.
Just for clarification: All IOMMU's
On Fri, 1 May 2020 17:37:47 +0200
Mauro Carvalho Chehab wrote:
> As we moved those files to core-api, fix references to point
> to their newer locations.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/PCI/pci.rst | 6 +++---
>
On 2020-05-15 17:14, Joerg Roedel wrote:
On Fri, May 15, 2020 at 04:42:23PM +0100, Robin Murphy wrote:
struct iommu_domain *iommu_get_dma_domain(struct device *dev)
{
- return dev->iommu_group->default_domain;
+ struct iommu_domain *domain = dev->iommu_group->default_domain;
+
On Fri, May 15, 2020 at 04:42:23PM +0100, Robin Murphy wrote:
> > struct iommu_domain *iommu_get_dma_domain(struct device *dev)
> > {
> > - return dev->iommu_group->default_domain;
> > + struct iommu_domain *domain = dev->iommu_group->default_domain;
> > +
> > + if
Hi,
On Fri, May 15, 2020 at 10:19:49AM -0700, Raj, Ashok wrote:
> On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote:
> > Can you please lift the untrusted flag into struct device? It really
> > isn't a PCI specific concept, and we should not have code poking into
> > pci_dev all
On Fri, May 15, 2020 at 12:43:59PM +0200, Jean-Philippe Brucker wrote:
> Add pci_ats_supported(), which checks whether a device has an ATS
> capability, and whether it is trusted. A device is untrusted if it is
> plugged into an external-facing port such as Thunderbolt and could be
> spoof an
On 2020-05-15 22:33, Song Bao Hua wrote:
Subject: Re: Constantly map and unmap of streaming DMA buffers with
IOMMU backend might cause serious performance problem
On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
Meanwhile, for the safety of buffers, lower-layer drivers need to
Hi,
On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote:
>
> This patch simply adds a new compatible string for SC7180 platform.
>
> Signed-off-by: Sharat Masetty
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 2020-05-15 19:26, Joerg Roedel wrote:
On Fri, May 15, 2020 at 05:28:53PM +0100, Robin Murphy wrote:
On 2020-05-15 17:14, Joerg Roedel wrote:
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ba128d1cdaee..403fda04ea98 100644
--- a/drivers/iommu/dma-iommu.c
+++
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Friday, May 15, 2020 2:59 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Lu Baolu
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
>
> On Thu, May 14, 2020 at 11:12:52PM
> Subject: Re: Constantly map and unmap of streaming DMA buffers with
> IOMMU backend might cause serious performance problem
>
> On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
> >> Meanwhile, for the safety of buffers, lower-layer drivers need to make
> certain the buffers have
> From: Alex Williamson
> Sent: Saturday, May 16, 2020 1:59 AM
>
> On Fri, 15 May 2020 07:39:14 +
> "Tian, Kevin" wrote:
>
> > Hi, Alex,
> >
> > When working on an updated version Yi and I found an design open
> > which needs your guidance.
> >
> > In concept nested translation can be
> Subject: Re: Constantly map and unmap of streaming DMA buffers with
> IOMMU backend might cause serious performance problem
>
> On 2020-05-15 09:19, Song Bao Hua wrote:
> [ snip... nice analysis, but ultimately it's still "doing stuff has more
> overhead
> than not doing stuff" ]
>
> > I am
> From: Raj, Ashok
> Sent: Friday, May 15, 2020 11:20 PM
>
> On Fri, May 15, 2020 at 12:39:14AM -0700, Tian, Kevin wrote:
> > Hi, Alex,
> >
> > When working on an updated version Yi and I found an design open
> > which needs your guidance.
> >
> > In concept nested translation can be incarnated
On Tue, 2020-04-14 at 15:15 +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Convert the Mediatek-v1 IOMMU driver to use the probe_device() and
> release_device() call-backs of iommu_ops, so that the iommu core code
> does the group and sysfs setup.
>
> Signed-off-by: Joerg Roedel
> ---
>
Hey Will,
On 2020-05-11 23:25, Sibi Sankar wrote:
The modem remote processor has two access paths to DDR. One path is
directly connected to DDR and another path goes through an SMMU. The
SMMU path is configured to be a direct mapping because it's used by
various peripherals in the modem
Hi, Alex,
When working on an updated version Yi and I found an design open
which needs your guidance.
In concept nested translation can be incarnated as one GPA->HPA page
table and multiple GVA->GPA page tables per VM. It means one container
is sufficient to include all SVA-capable devices
The MediaTek V1 IOMMU is arm32 whose default domain type is
IOMMU_DOMAIN_UNMANAGED. Add this to satisfy the bus_iommu_probe to
enter "probe_finalize".
The iommu framework will create a iommu domain for each a device.
But all the devices share a iommu domain here, thus we skip all the
other
Hi Russell & All,
In many DMA streaming map/unmap use cases, lower-layer device drivers
completely have no idea how and when single/sg buffers are allocated and freed
by upper-layer filesystem, network protocol, mm management system etc. So the
only thing device drivers can do is constantly
From: Joerg Roedel
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
But this needs support from the dma-ops code too, to actually do
Hi,
On Wed 13 May 20, 16:07, Maxime Ripard wrote:
> The main DRM device is actually a virtual device so it doesn't have the
> iommus property, which is instead on the DMA masters, in this case the
> mixers.
>
> Add a call to of_dma_configure with the mixers DT node but on the DRM
> virtual
On Thu, May 14, 2020 at 11:12:52PM +, Prakhya, Sai Praneeth wrote:
> +static int is_driver_bound(struct device *dev, void *not_used)
> +{
> + int ret = 0;
> +
> + device_lock(dev);
> + if (device_is_bound(dev))
> + ret = 1;
> + device_unlock(dev);
> + return
On Wed, May 13, 2020 at 03:47:21PM -0700, Sai Praneeth Prakhya wrote:
> After moving iommu_group setup to iommu core code [1][2] and removing
> private domain support in vt-d [3], there are no users for functions such
> as iommu_request_dm_for_dev(), iommu_request_dma_domain_for_dev() and
>
Hi,
On Fri, May 15, 2020 at 03:44:59PM +0800, Yong Wu wrote:
> On Tue, 2020-04-14 at 15:15 +0200, Joerg Roedel wrote:
> > - return iommu_device_link(>iommu, dev);
> > + err = arm_iommu_attach_device(dev, mtk_mapping);
> > + if (err)
> > + dev_err(dev, "Can't create IOMMU mapping -
On Wed, May 13, 2020 at 03:32:32PM +0200, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
>
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index acb26c6..89e293b 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -63,10 +63,9 @@ static struct sg_table *get_sg_table(struct device *dev,
> struct dma_buf *buf,
>
Add pci_ats_supported(), which checks whether a device has an ATS
capability, and whether it is trusted. A device is untrusted if it is
plugged into an external-facing port such as Thunderbolt and could be
spoof an existing device to exploit weaknesses in the IOMMU
configuration. PCIe ATS is one
The new pci_ats_supported() function checks if a device supports ATS and
is allowed to use it.
Signed-off-by: Jean-Philippe Brucker
---
I dropped the Ack because I slightly changed the patch to keep the
fwspec check, since last version:
The pci_ats_supported() helper checks if a device supports ATS and is
allowed to use it. By checking the ATS capability it also integrates the
pci_ats_disabled() check from pci_ats_init(). Simplify the vt-d checks.
Acked-by: Lu Baolu
Signed-off-by: Jean-Philippe Brucker
---
I sent these in March as part of ATS enablement for device-tree [1], but
haven't found the time to address the largest comment on that series
about consolidating the root bridge ATS support between the different
ACPI tables.
I'm resending only the bits that consolidate the 'untrusted' check for
The pci_ats_supported() function checks if a device supports ATS and is
allowed to use it. In addition to checking that the device has an ATS
capability and that the global pci=noats is not set
(pci_ats_disabled()), it also checks if a device is untrusted.
A device is untrusted if it is plugged
46 matches
Mail list logo
