On 2020/5/14 7:01, Jacob Pan wrote:
Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel
platforms allow address space sharing between device DMA and applications.
SVA can reduce programming complexity and enhance security.
This series is intended to enable SVA virtualization
From: Jacob Pan
Query Shared Virtual Address/Memory capability is a generic feature.
SVA feature check is the required first step before calling
iommu_sva_bind_device().
VT-d checks SVA feature enabling at per IOMMU level during this step,
SVA bind device will check and enable PCI ATS, PRS, and
Enabling IOMMU in a guest requires communication with the host
driver for certain aspects. Use of PASID ID to enable Shared Virtual
Addressing (SVA) requires managing PASID's in the host. VT-d 3.0 spec
provides a Virtual Command Register (VCMD) to facilitate this.
Writes to this register in the gue
When a PASID is stopped or terminated, there can be pending PRQs
(requests that haven't received responses) in remapping hardware.
This adds the interface to drain page requests and call it when a
PASID is terminated.
Signed-off-by: Jacob Pan
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
Add a get_domain_info() helper to retrieve the valid per-device
iommu private data.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 40 +
drivers/iommu/intel-pasid.c | 12 +--
drivers/iommu/intel-svm.c | 2 +-
include/linux/intel-iommu.h |
From: Jacob Pan
When supporting guest SVA with emulated IOMMU, the guest PASID
table is shadowed in VMM. Updates to guest vIOMMU PASID table
will result in PASID cache flush which will be passed down to
the host as bind guest PASID calls.
For the SL page tables, it will be harvested from device'
From: Jacob Pan
An Intel iommu domain uses 5-level page table by default. If the iommu
that the domain tries to attach supports less page levels, the top level
page tables should be skipped. Add a helper to do this so that it could
be used in other places.
Signed-off-by: Jacob Pan
Reviewed-by:
Current qi_submit_sync() only supports single invalidation descriptor
per submission and appends wait descriptor after each submission to
poll the hardware completion. This extends the qi_submit_sync() helper
to support multiple descriptors, and add an option so that the caller
could specify the Pa
Hi Joerg,
Below patches have been piled up for v5.8. They enable below features:
- Nested Shared Virtual Address (SVA) VT-d support
- Replace Intel SVM with IOMMU SVA APIs
- SVA page request draining support
Can you please consider them for iommu/next?
Best regards,
Lu Baolu
Jacob Pan (9):
Export invalidation queue internals of each iommu device through the
debugfs.
Example of such dump on a Skylake machine:
$ sudo cat /sys/kernel/debug/iommu/intel/invalidation_queue
Invalidation queue on IOMMU: dmar1
Base: 0x1672c9000 Head: 80Tail: 80
Index qw0
From: Jacob Pan
This patch is an initial step to replace Intel SVM code with the
following IOMMU SVA ops:
intel_svm_bind_mm() => iommu_sva_bind_device()
intel_svm_unbind_mm() => iommu_sva_unbind_device()
intel_svm_is_pasid_valid() => iommu_sva_get_pasid()
The features below will continue to work
IOTLB flush already included in the PASID tear down and the page request
drain process. There is no need to flush again.
Signed-off-by: Jacob Pan
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
---
drivers/iommu/intel-svm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
When a PASID is used for SVA by the device, it's possible that the PASID
entry is cleared before the device flushes all ongoing DMA requests. The
IOMMU should tolerate and ignore the non-recoverable faults caused by the
untranslated requests from this device.
For example, when an exception happens
From: Jacob Pan
Nested translation mode is supported in VT-d 3.0 Spec.CH 3.8.
With PASID granular translation type set to 0x11b, translation
result from the first level(FL) also subject to a second level(SL)
page table translation. This mode is used for SVA virtualization,
where FL performs guest
From: Jacob Pan
When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
IOTLB invalidation may be passed down from outside IOMMU subsystems.
This patch adds invalidation functions that can be used for additional
translation cache types.
Signed-off-by: Jacob Pan
Reviewed-by: Eric A
From: Jacob Pan
When VT-d driver runs in the guest, PASID allocation must be
performed via virtual command interface. This patch registers a
custom IOASID allocator which takes precedence over the default
XArray based allocator. The resulting IOASID allocation will always
come from the host. This
From: Tom Murphy
There's no need for the non-dma_ops path to keep track of IOVAs. The
whole point of the non-dma_ops path is that it allows the IOVAs to be
handled separately. The IOVA handling code removed in this patch is
pointless.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
driv
The info and info->pasid_support have already been checked in previous
intel_iommu_enable_pasid() call. No need to check again.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
inde
From: Jacob Pan
When Shared Virtual Address (SVA) is enabled for a guest OS via
vIOMMU, we need to provide invalidation support at IOMMU API and driver
level. This patch adds Intel VT-d specific function to implement
iommu passdown invalidate API for shared virtual address.
The use case is for s
From: Jacob Pan
Move domain helper to header to be used by SVA code.
Signed-off-by: Jacob Pan
Reviewed-by: Eric Auger
Reviewed-by: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 6 --
include/linux/intel-iommu.h | 6 ++
2 files changed, 6 insertions(+), 6 delet
Hi Jacob,
On 2020/5/14 23:57, Jacob Pan wrote:
Hi Christoph,
Thanks a lot for the reviews, comments below.
Jacob
On Wed, 13 May 2020 22:59:30 -0700
Christoph Hellwig wrote:
+ if (dev_is_pci(dev)) {
+ /* VT-d supports devices with full 20 bit PASIDs
only */
+
> 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 a
> 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 incar
> 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 th
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 make
> 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 alr
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 exis
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
+++ b/driver
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 a/Documentation
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 +,
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, 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 mea
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 +++---
> Documentation/block/biod
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 o
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 to
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 (__iommu_is_attach_defe
On Fri, May 15, 2020 at 08:55:42PM +0800, Lu Baolu wrote:
> It seems that we can do like this:
>
> [1] mutex_lock(&group->lock)
> [2] for_each_group_device(device_lock())
> [3] if (for_each_group_device(!device_is_bound()))
> change_default_domain()
> [4] for_each_group_device_reverse(device
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
https://lists.linuxfoundat
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 support
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, 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 bene
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;
>
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 nee
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: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() set
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
> > capability
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 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 a
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
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
---
drivers/iommu/intel-
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:
https://lore.kernel.org/linux-iommu/20200311124506.208376-8-
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
AT
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 in
> 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,
>
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
> dma_unmap_sg
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(&data->iommu, dev);
> > + err = arm_iommu_attach_device(dev, mtk_mapping);
> > + if (err)
> > + dev_err(dev, "Can't create IOMMU mapp
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
> request
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 ret;
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 device
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 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 map
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 subsyste
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 domains
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
> ---
> d
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 assign
67 matches
Mail list logo
