On Fri, Nov 08, 2019 at 04:44:25PM +, John Garry wrote:
> On 08/11/2019 16:17, John Garry wrote:
> > On 08/11/2019 15:16, Will Deacon wrote:
> > > +MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
> >
> > Hi Will,
> >
> > > static struct platform_driver arm_smmu_driver = {
> > > .driver
On Fri, Nov 08, 2019 at 05:25:09PM +, John Garry wrote:
> On 08/11/2019 16:47, Will Deacon wrote:
> > On Fri, Nov 08, 2019 at 04:44:25PM +, John Garry wrote:
> > > BTW, it now looks like it was your v1 series I was testing there, on your
> > > branch iommu/module. It would be helpful to
On 08/11/2019 17:32, Will Deacon wrote:
On Fri, Nov 08, 2019 at 05:25:09PM +, John Garry wrote:
On 08/11/2019 16:47, Will Deacon wrote:
On Fri, Nov 08, 2019 at 04:44:25PM +, John Garry wrote:
BTW, it now looks like it was your v1 series I was testing there, on your
branch
On Fri, Nov 08, 2019 at 05:32:48PM +, Will Deacon wrote:
> On Fri, Nov 08, 2019 at 05:25:09PM +, John Garry wrote:
> > On 08/11/2019 16:47, Will Deacon wrote:
> > > On Fri, Nov 08, 2019 at 04:44:25PM +, John Garry wrote:
> > > > BTW, it now looks like it was your v1 series I was
On 08/11/2019 17:48, Will Deacon wrote:
On Fri, Nov 08, 2019 at 05:32:48PM +, Will Deacon wrote:
On Fri, Nov 08, 2019 at 05:25:09PM +, John Garry wrote:
On 08/11/2019 16:47, Will Deacon wrote:
On Fri, Nov 08, 2019 at 04:44:25PM +, John Garry wrote:
BTW, it now looks like it was
On 08/11/2019 16:17, John Garry wrote:
On 08/11/2019 15:16, Will Deacon wrote:
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
Hi Will,
static struct platform_driver arm_smmu_driver = {
.driver = {
.name = "arm-smmu-v3",
.of_match_table =
On 08/11/2019 16:47, Will Deacon wrote:
On Fri, Nov 08, 2019 at 04:44:25PM +, John Garry wrote:
On 08/11/2019 16:17, John Garry wrote:
On 08/11/2019 15:16, Will Deacon wrote:
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
Hi Will,
static struct platform_driver arm_smmu_driver = {
Hi Eric,
On 11/8/19 11:58 PM, Eric Auger wrote:
For both PASID-based-Device-TLB Invalidate Descriptor and
Device-TLB Invalidate Descriptor, the Physical Function Source-ID
value is split according to this layout:
PFSID[3:0] is set at offset 12 and PFSID[15:4] is put at offset 52.
Fix the part
> > + x86_platform.iommu_shutdown = intel_iommu_shutdown;
>
> How about moving it to detect_intel_iommu() in drivers/iommu/dmar.c? And
Ok, makes sense to move it along with the init handler.
> make sure that it's included with CONFIG_X86_64.
You mean CONFIG_X86 like the init that is already
On Fri, 8 Nov 2019 16:58:03 +0100
Eric Auger wrote:
> For both PASID-based-Device-TLB Invalidate Descriptor and
> Device-TLB Invalidate Descriptor, the Physical Function Source-ID
> value is split according to this layout:
>
> PFSID[3:0] is set at offset 12 and PFSID[15:4] is put at offset 52.
> On Nov 8, 2019, at 10:40 PM, Lu Baolu wrote:
>
> This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> to make it easier for distributions to enable or disable the
> Intel IOMMU scalable mode by default during kernel build.
>
> Signed-off-by: Lu Baolu
> ---
>
> > > For VMM live update case, we should be able to detect and bypass
> > > the shutdown that Deepa introduced here, so keep IOMMU still operating?
> >
> > Is that a 'yes' to Deepa's "if someone wants to make it conditional, we
> > can do that" ?
>
> Yes, I think so. Thanks!
Are these changes
This adds Kconfig option INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
to make it easier for distributions to enable or disable the
Intel IOMMU scalable mode by default during kernel build.
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 9 +
drivers/iommu/intel-iommu.c | 7 ++-
2
On Fri, 8 Nov 2019 11:40:23 +0100
Auger Eric wrote:
> Hi Jacob,
>
> On 10/24/19 9:54 PM, Jacob Pan wrote:
> > 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
On Fri, 8 Nov 2019 12:30:31 +0100
Auger Eric wrote:
> Hi Jacob,
>
> On 10/24/19 9:54 PM, Jacob Pan wrote:
> > Make use of generic IOASID code to manage PASID allocation,
> > free, and lookup. Replace Intel specific code.
> >
> > Signed-off-by: Jacob Pan
> > ---
> >
Hi,
On 11/9/19 6:28 AM, Deepa Dinamani wrote:
+ x86_platform.iommu_shutdown = intel_iommu_shutdown;
How about moving it to detect_intel_iommu() in drivers/iommu/dmar.c? And
Ok, makes sense to move it along with the init handler.
make sure that it's included with CONFIG_X86_64.
You
On Fri, 8 Nov 2019 17:18:10 +0100
Auger Eric wrote:
> Hi Jacob,
>
> On 10/24/19 9:55 PM, Jacob Pan wrote:
> > 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
For both PASID-based-Device-TLB Invalidate Descriptor and
Device-TLB Invalidate Descriptor, the Physical Function Source-ID
value is split according to this layout:
PFSID[3:0] is set at offset 12 and PFSID[15:4] is put at offset 52.
Fix the part laid out at offset 52.
Fixes: 0f725561e1684
Hi Jacob,
On 10/24/19 9:55 PM, Jacob Pan wrote:
> 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.
>
>
On 08/11/2019 15:16, Will Deacon wrote:
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
Hi Will,
static struct platform_driver arm_smmu_driver = {
.driver = {
.name = "arm-smmu-v3",
.of_match_table = of_match_ptr(arm_smmu_of_match),
-
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> Make use of generic IOASID code to manage PASID allocation,
> free, and lookup. Replace Intel specific code.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel-iommu.c | 12 ++--
> drivers/iommu/intel-pasid.c | 36
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> From: Lu Baolu
>
> 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
Hi Joerg,
On Tue, Nov 05, 2019 at 01:15:08PM +0100, Joerg Roedel wrote:
> On Thu, Oct 31, 2019 at 03:42:47PM +, Will Deacon wrote:
> > Generally, I think unloading the IOMMU driver module while there are
> > active users is a pretty bad idea, much like unbinding the driver via
> > /sys in the
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device,
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device, which share
data
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) is
a kernel module targets to provide Shared Virtual Addressing (SVA)
between the accelerator and process.
This patch add document to explain how it works.
Signed-off-by: Kenneth Lee
Signed-off-by: Zaibo Xu
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 8, 2019 6:07 AM
> To: Liu, Yi L
> Subject: Re: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)
>
> On Wed, 6 Nov 2019 13:27:26 +
> "Liu, Yi L" wrote:
>
> > > From: Alex Williamson
> > >
Register qm to uacce framework for user crypto driver
Signed-off-by: Zhangfei Gao
Signed-off-by: Zhou Wang
---
drivers/crypto/hisilicon/qm.c | 256 ++--
drivers/crypto/hisilicon/qm.h | 11 ++
drivers/crypto/hisilicon/zip/zip_main.c | 38 ++---
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> Virtual command registers are used in the guest only, to prevent
> vmexit cost, we cache the capability and store it during initialization.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/dmar.c| 1 +
> include/linux/intel-iommu.h |
Hi Jacob,
On 10/24/19 9:54 PM, Jacob Pan wrote:
> 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
On Fri, 2019-11-08 at 08:47 +, Zeng, Jason wrote:
> > -Original Message-
> > From: David Woodhouse
> > Sent: Friday, November 8, 2019 3:54 PM
> > To: Deepa Dinamani ; j...@8bytes.org; linux-
> > ker...@vger.kernel.org
> > Cc: iommu@lists.linux-foundation.org; Zeng, Jason ;
> > Tian,
On Fri, 8 Nov 2019 12:23:41 +
"Liu, Yi L" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 8, 2019 6:07 AM
> > To: Liu, Yi L
> > Subject: Re: [RFC v2 2/3] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)
> >
> > On Wed, 6 Nov 2019 13:27:26
To avoid accidental removal of an active IOMMU driver module, take a
reference to the driver module in 'iommu_probe_device()' immediately
prior to invoking the '->add_device()' callback and hold it until the
after the device has been removed by '->remove_device()'.
Suggested-by: Joerg Roedel
This reverts commit c07b6426df922d21a13a959cf785d46e9c531941.
Let's get the SMMUv3 driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu-v3.c | 25 -
1 file changed, 16
By removing the redundant call to 'pci_request_acs()' we can allow the
ARM SMMUv3 driver to be built as a module.
Signed-off-by: Will Deacon
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
By conditionally dropping support for the legacy binding and exporting
the newly introduced 'arm_smmu_impl_init()' function we can allow the
ARM SMMU driver to be built as a module.
Signed-off-by: Will Deacon
---
drivers/iommu/Kconfig| 14 +-
drivers/iommu/Makefile | 3 ++-
Hi all,
This is version two of the patches I previously posted here:
https://lore.kernel.org/lkml/20191030145112.19738-1-w...@kernel.org/
Changes since v1 include:
* Build single "arm-smmu-mod.ko" module for the Arm SMMU driver
* Hold a reference to the IOMMU driver module across
Building drivers for ATS-aware IOMMUs as modules requires access to
pci_ats_disabled(). Export it as a GPL symbol to get things working.
Acked-by: Bjorn Helgaas
Signed-off-by: Will Deacon
---
drivers/pci/pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/pci.c
Building IOMMU drivers as modules requires that the core IOMMU API
symbols are exported as GPL symbols.
Signed-off-by: Will Deacon
---
drivers/iommu/iommu-sysfs.c | 5 +
drivers/iommu/iommu.c | 8
2 files changed, 13 insertions(+)
diff --git a/drivers/iommu/iommu-sysfs.c
To avoid having to export 'pci_request_acs()' to modular IOMMU drivers,
move the call into the 'of_dma_configure()' path in a similar manner to
the way in which ACS is configured when probing via ACPI/IORT.
Signed-off-by: Will Deacon
---
drivers/iommu/of_iommu.c | 1 +
1 file changed, 1
This reverts commit addb672f200f4e99368270da205320b83efe01a0.
Let's get the SMMU driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu.c | 32 +++-
1 file changed, 19
Ensure that we hold a reference to the IOMMU driver module while calling
the '->of_xlate()' callback during early device probing.
Signed-off-by: Will Deacon
---
drivers/iommu/of_iommu.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git
Named component nodes in the IORT tables describe the number of
Substream ID bits (aka. PASID) supported by the device. Propagate this
value to the fwspec structure in order to enable PASID for platform
devices.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 18
This is version 2 of the series I sent a while ago [1], adding PASID
support to the Arm SMMUv3 driver.
Changes since v1:
* Dropped the patch adding auxiliary domain support. It's an easy way to
test PASID, by populating PASID contexts using iommu_map/unmap(), but
I don't know if it will ever
The SMMU can support up to 20 bits of SSID. Add a second level of page
tables to accommodate this. Devices that support more than 1024 SSIDs now
have a table of 1024 L1 entries (8kB), pointing to tables of 1024 context
descriptors (64kB), allocated on demand.
Signed-off-by: Jean-Philippe Brucker
At the moment, the SMMUv3 driver implements only one stage-1 or stage-2
page directory per device. However SMMUv3 allows more than one address
space for some devices, by providing multiple stage-1 page directories. In
addition to the Stream ID (SID), that identifies a device, we can now have
For platform devices that support SubstreamID (SSID), firmware provides
the number of supported SSID bits. Restrict it to what the SMMU supports
and cache it into master->ssid_bits, which will also be used for PCI
PASID.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 13
When a master supports substream ID, allocate a table with multiple
context descriptors for its stage-1 domain. For the moment S1CDMax is
still 0 in the STE, so the additional context descriptors are ignored.
Context descriptor tables are allocated once for the first master attached
to a domain.
Let add_device() clean up after itself. The iommu_bus_init() function
does call remove_device() on error, but other sites (e.g. of_iommu) do
not.
Don't free level-2 stream tables because we'd have to track if we
allocated each of them or if they are used by other endpoints. It's not
worth the
Enable PASID for PCI devices that support it. Since the SSID tables are
allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
arm_smmu_dev_feature_enable() would be too late, since by that time the
main DMA domain has already been attached. Do it in add_device() instead.
On Arm systems, some platform devices behind an SMMU may support the PASID
feature, which offers multiple address space. Let the firmware tell us
when a device supports PASID.
Reviewed-by: Rob Herring
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
> -Original Message-
> From: David Woodhouse
> Sent: Friday, November 8, 2019 4:57 PM
> To: Zeng, Jason ; Deepa Dinamani
> ; j...@8bytes.org; linux-ker...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org; Tian, Kevin
> Subject: Re: [PATCH] intel-iommu: Turn off translations at
> -Original Message-
> From: David Woodhouse
> Sent: Friday, November 8, 2019 3:54 PM
> To: Deepa Dinamani ; j...@8bytes.org; linux-
> ker...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org; Zeng, Jason ;
> Tian, Kevin
> Subject: Re: [PATCH] intel-iommu: Turn off translations at
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device, which share
data
Register qm to uacce framework for user crypto driver
Signed-off-by: Zhangfei Gao
Signed-off-by: Zhou Wang
---
drivers/crypto/hisilicon/qm.c | 256 ++--
drivers/crypto/hisilicon/qm.h | 11 ++
drivers/crypto/hisilicon/zip/zip_main.c | 38 ++---
Hi Jean-Philippe,
On Mon, Nov 04, 2019 at 08:15:24PM +0100, Jean-Philippe Brucker wrote:
> On Thu, Oct 31, 2019 at 03:42:47PM +, Will Deacon wrote:
> > > Sorry for the stupid question, but what prevents the iommu module from
> > > being unloaded when there are active users? There are no
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) is
a kernel module targets to provide Shared Virtual Addressing (SVA)
between the accelerator and process.
This patch add document to explain how it works.
Signed-off-by: Kenneth Lee
Signed-off-by: Zaibo Xu
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device,
Hi Jacob,
On 10/24/19 9:55 PM, Jacob Pan wrote:
> 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
59 matches
Mail list logo
