Second-level context descriptor tables will be allocated lazily in
arm_smmu_write_ctx_desc(). Help with handling allocation failure by
moving the CD write into arm_smmu_domain_finalise_s1().
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers
-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 33f71983e001..39f389214ecf 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -11,6
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: Eric Auger
Reviewed-by: Jonathan Cameron
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
On Tue, Jan 14, 2020 at 03:04:36PM +, Will Deacon wrote:
> On Thu, Dec 19, 2019 at 05:30:30PM +0100, Jean-Philippe Brucker wrote:
> > 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
On Tue, Jan 14, 2020 at 12:45:42PM +, Will Deacon wrote:
> On Thu, Dec 19, 2019 at 05:30:33PM +0100, Jean-Philippe Brucker wrote:
> > Enable PASID for PCI devices that support it. Since the SSID tables are
> > allocated by arm_smmu_attach_dev(), PASID has to be enabl
On Tue, Jan 14, 2020 at 12:42:47PM +, Will Deacon wrote:
> On Thu, Dec 19, 2019 at 05:30:29PM +0100, Jean-Philippe Brucker wrote:
> > Second-level context descriptor tables will be allocated lazily in
> > arm_smmu_write_ctx_desc(). Help with handling allocation failure by
&g
On Tue, Jan 14, 2020 at 12:38:19PM +, Will Deacon wrote:
> > +static void arm_smmu_sync_cd(struct arm_smmu_domain *smmu_domain,
> > +int ssid, bool leaf)
> > +{
> > + size_t i;
> > + unsigned long flags;
> > + struct arm_smmu_master *master;
> > + struct arm_smmu
On Tue, Jan 14, 2020 at 11:06:52AM +, Will Deacon wrote:
> > /* Context descriptor manipulation functions */
> > +static int arm_smmu_alloc_cd_leaf_table(struct arm_smmu_device *smmu,
> > + struct arm_smmu_cd_table *table,
> > +
On Thu, Jan 09, 2020 at 02:41:01PM +, Will Deacon wrote:
> On Thu, Jan 09, 2020 at 03:36:18PM +0100, Jean-Philippe Brucker wrote:
> > On Thu, Dec 19, 2019 at 05:30:20PM +0100, Jean-Philippe Brucker wrote:
> > > Add support for Substream ID and PASIDs to the SMMUv3 driver. Sin
Hi Will,
On Thu, Dec 19, 2019 at 05:30:20PM +0100, Jean-Philippe Brucker wrote:
> Add support for Substream ID and PASIDs to the SMMUv3 driver. Since v3
> [1], I added review and tested tags where appropriate and applied the
> suggested changes, shown in the diff below. Thanks all!
Support for SSID will require allocating context descriptor tables. Move
the context descriptor allocation to separate functions.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 57
vert
DMA buffer allocations to the managed API"), since the managed API
didn't provide a dmam_zalloc_coherent() function.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 9 -
1 file changed, 4 insertions
eviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
include/linux/pci-ats.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index 5d62e78946a3..d08f0869f121 100644
--- a/include/linux/pci-ats.h
+++
but as with stream and page tables, an SSID can
be split to index multiple levels of tables.
Tested-by: Zhangfei Gao
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 125 +---
1 file ch
ean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 13 +
drivers/iommu/of_iommu.c| 6 +-
include/linux/iommu.h | 2 ++
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index d4e8b7f8d
Second-level context descriptor tables will be allocated lazily in
arm_smmu_write_ctx_desc(). Help with handling allocation failure by
moving the CD write into arm_smmu_domain_finalise_s1().
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers
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: Eric Auger
Reviewed-by: Jonathan Cameron
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
.
Tested-by: Zhangfei Gao
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 55 -
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index
s not
worth the hassle since they are managed resources.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/
When adding SSID support to the SMMUv3 driver, we'll need to manipulate
leaf pasid tables and context descriptors. Extract the context
descriptor structure and introduce a new table structure.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Br
: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 154 +---
1 file changed, 144 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index b825a5639afc..bf106a7b53eb 100644
-git-send-email-zhangfei....@linaro.org/
Jean-Philippe Brucker (13):
iommu/arm-smmu-v3: Drop __GFP_ZERO flag from DMA allocation
dt-bindings: document PASID property for IOMMU masters
iommu/arm-smmu-v3: Parse PASID devicetree property of platform devices
ACPI/IORT: Parse SSID property of
-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 33f71983e001..39f389214ecf 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -11,6
rying SSID size
is less of a concern, since the PCIe specification "highly recommends"
that devices supporting PASID implement all 20 bits of it.
Tested-by: Zhangfei Gao
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iomm
On Wed, Dec 18, 2019 at 11:17:55AM +0100, Auger Eric wrote:
> > +static int arm_smmu_enable_pasid(struct arm_smmu_master *master)
> > +{
> > + int ret;
> > + int features;
> > + int num_pasids;
> > + struct pci_dev *pdev;
> > +
> > + if (!dev_is_pci(master->dev))
> > + return -E
On Wed, Dec 18, 2019 at 10:59:36AM +0100, Auger Eric wrote:
> > struct arm_smmu_s1_cfg {
> > - struct arm_smmu_cd_tabletable;
> > + struct arm_smmu_cd_table*tables;
> > + size_t num_tables;
> > + __le64 *l1ptr;
> you may add
On Tue, Dec 17, 2019 at 06:07:26PM +0100, Auger Eric wrote:
> Hi Jean,
>
> On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
>
> s/Propate/Propagate in the commit title.
> > Now that we support substream IDs, initialize s1cdmax with the number of
> > SSID bits support
On Tue, Dec 17, 2019 at 05:43:59PM +0100, Auger Eric wrote:
> > -static void arm_smmu_write_ctx_desc(struct arm_smmu_device *smmu,
> > - struct arm_smmu_s1_cfg *cfg)
> > +static int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain,
> > +
On Wed, Dec 18, 2019 at 11:17:40AM +0100, Auger Eric wrote:
> Hi Jean,
>
> On 12/9/19 7:05 PM, Jean-Philippe Brucker wrote:
> > For platform devices that support SubstreamID (SSID), firmware provides
> > the number of supported SSID bits. Restrict it to what the SMMU supp
On Tue, Dec 03, 2019 at 07:01:36PM -0800, Jacob Pan (Jun) wrote:
> Hi Jean,
>
> Sorry for the delay, I was out last week. Comments inline below.
>
> On Mon, 25 Nov 2019 19:02:47 +0100
> Jean-Philippe Brucker wrote:
>
> > On Fri, Nov 22, 2019 at 04:01:02PM -
Hi Eric,
On Tue, Dec 17, 2019 at 12:05:18PM +0100, Auger Eric wrote:
> > + fwspec = dev_iommu_fwspec_get(dev);
> > + if (!err && fwspec)
> > + of_property_read_u32(master_np, "pasid-num-bits",
> > +&fwspec->num_pasid_bit
On Mon, Dec 09, 2019 at 03:50:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Use the new standard function instead of open-coding it.
>
> Cc: Jean-Philippe Brucker
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Thierry Reding
Reviewed-by:
.
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index d20a79108f8a..cde7af39681c 100644
rying SSID size
is less of a concern, since the PCIe specification "highly recommends"
that devices supporting PASID implement all 20 bits of it.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 19 ---
1 file changed, 16 insertions(+), 3 deleti
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
lore.kernel.org/linux-iommu/20191108152508.4039168-1-jean-phili...@linaro.org/
Jean-Philippe Brucker (13):
iommu/arm-smmu-v3: Drop __GFP_ZERO flag from DMA allocation
dt-bindings: document PASID property for IOMMU masters
iommu/arm-smmu-v3: Support platform SSID
ACPI/IORT: Support PASID for p
Support for SSID will require allocating context descriptor tables. Move
the context descriptor allocation to separate functions.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 57 ++---
1 file changed, 46 insertions(+), 11 deletions
vert
DMA buffer allocations to the managed API"), since the managed API
didn't provide a dmam_zalloc_coherent() function.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c
The SMMUv3 driver, which may be built without CONFIG_PCI, will soon gain
PASID support. Partially revert commit c6e9aefbf9db ("PCI/ATS: Remove
unused PRI and PASID stubs") to re-introduce the PASID stubs, and avoid
adding more #ifdefs to the SMMU driver.
Signed-off-by: Jean-Philip
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
---
Documentation/devicetree
but as with stream and page tables, an SSID can
be split to index multiple levels of tables.
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 125 +---
1 file changed, 102 insertions(+), 23 deletions(-)
diff --git
When adding SSID support to the SMMUv3 driver, we'll need to manipulate
leaf pasid tables and context descriptors. Extract the context
descriptor structure and introduce a new table structure.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c
Second-level context descriptor tables will be allocated lazily in
arm_smmu_write_ctx_desc(). Help with handling allocation failure by
moving the CD write into arm_smmu_domain_finalise_s1().
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 11 +++
1 file changed, 7
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.
Acked-by: Hanjun Guo
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64
s not
worth the hassle since they are managed resources.
Reviewed-by: Eric Auger
Reviewed-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/
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 |
On Mon, Dec 09, 2019 at 12:55:22PM +, Robin Murphy wrote:
> On 09/12/2019 12:38 pm, Jean-Philippe Brucker wrote:
> > Since commit 781ca2de89ba ("iommu: Add gfp parameter to
> > iommu_ops::map"), iommu_map() might sleep. iommu_dma_get_msi_page() runs
> > in atom
Since commit 781ca2de89ba ("iommu: Add gfp parameter to
iommu_ops::map"), iommu_map() might sleep. iommu_dma_get_msi_page() runs
in atomic context and thus should call iommu_map_atomic() instead.
Fixes: 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map")
Signed-o
On Fri, Nov 22, 2019 at 04:01:02PM -0800, Jacob Pan (Jun) wrote:
> > (1) ACPI has one table per vendor (DMAR for Intel, IVRS for AMD and
> > IORT for Arm). From my point of view IORT is easier to extend, since
> > we just need to introduce a new node type. There are no dependencies
> > to Arm in th
On Fri, Nov 22, 2019 at 08:00:46AM -0500, Michael S. Tsirkin wrote:
> > (2) In addition, there are some concerns about having virtio depend on
> > ACPI or DT. Some hypervisors (Firecracker, QEMU microvm, kvmtool x86
> > [1])
>
> power?
In kvmtool it boot with device tree. It also doesn't
On Fri, Nov 22, 2019 at 07:53:19AM -0500, Michael S. Tsirkin wrote:
> Overall this looks good to me. The only point is that
> I think the way the interface is designed makes writing
> the driver a bit too difficult. Idea: if instead we just
> have a length field and then an array of records
> (pref
On Mon, Nov 11, 2019 at 03:50:07PM +, Jonathan Cameron wrote:
> > + cfg->l1ptr = dmam_alloc_coherent(smmu->dev, size,
> > +&cfg->l1ptr_dma,
> > +GFP_KERNEL | __GFP_ZERO);
>
> As before. Fairly su
Hi Jonathan,
On Mon, Nov 11, 2019 at 04:05:29PM +, Jonathan Cameron wrote:
> On Fri, 8 Nov 2019 16:25:08 +0100
> Jean-Philippe Brucker wrote:
>
> > Enable PASID for PCI devices that support it. Since the SSID tables are
> > allocated by arm_smmu_attach_dev(), PASID ha
On Mon, Nov 11, 2019 at 02:38:11PM +, Jonathan Cameron wrote:
> Hmm. There are several different refactors in here alongside a few new
> bits. Would be nice to break it up more to make life even easier for
> reviewers. It's not 'so' complex that it's really a problem though
> so could leave
Add a new type of node to the IORT driver, that describes a virtio-iommu
device based on the virtio-mmio transport. The node is only available
when the IORT is a sub-table of the VIOT.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/iort.c | 66
When the IOMMU is PCI-based, IORT doesn't know the fwnode until the
driver has had a chance to register it. In addition to deferring the
probe until the IOMMU ops are set, also defer the probe until the fwspec
is available.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/iort.c
When the virtio-iommu uses the PCI transport and the topology is
described with IORT, register the PCI fwnode with IORT.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu
The current node filtering won't work when introducing node types
greater than 63 (such as the virtio-iommu nodes). Add
node_type_matches() to filter nodes by category.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/iort.c | 34 --
1 file change
mu if necessary, using the software_node framework.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/virtio-iommu.c | 56
1 file changed, 51 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 3ea9d76
and Kconfig entries.
Signed-off-by: Jean-Philippe Brucker
---
MAINTAINERS | 9 +
drivers/acpi/Kconfig| 3 +++
drivers/acpi/Makefile | 1 +
drivers/acpi/arm64/Kconfig | 3 ---
drivers/acpi/arm64/Makefile | 1 -
drivers/acpi/{arm64
supports PCI, not platform devices.
You can find Linux and QEMU code on my virtio-iommu/devel branches at
http://jpbrucker.net/git/linux and http://jpbrucker.net/git/qemu
I split the diffstat since there are two independent features. The first
one is for patches 1-11, and the second one for pat
Add a function to register an IORT table from an external source.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/iort.c | 22 --
include/linux/acpi_iort.h | 10 ++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/iort.c b
Add a lightweight method to describe the IOMMU topology in the config
space, guarded by a new feature bit. A list of capabilities in the
config space describes the devices managed by the IOMMU and their
endpoint IDs.
Signed-off-by: Jean-Philippe Brucker
---
virtio-iommu.tex | 88
This is temporary, until the VIOT table is published and these
definitions added to ACPICA.
Signed-off-by: Jean-Philippe Brucker
---
include/acpi/actbl2.h | 31 +++
1 file changed, 31 insertions(+)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index
When virtio-iommu uses the PCI transport, IORT doesn't instantiate the
device and doesn't create a fwnode. They will be created later by the
PCI subsystem. Store the information needed to identify the IOMMU in
iort_fwnode_list.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/io
x27;t
work with platform endpoints, which are references to items in the ACPI
table on IORT.
Signed-off-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
Note that we only call virt_dma_configure() if the host didn't provide
either DT or ACPI method. If you want to test this with QEMU, you
For a PCI-based IOMMU, IORT isn't in charge of allocating a fwnode. Let
the IOMMU driver update the fwnode associated to an IORT node when
available.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/iort.c | 38 ++
include/linux/acpi_iort.h
Add support for a new ACPI table that embeds other tables describing a
platform's IOMMU topology. Currently the only supported base table is
IORT. The VIOT contains an IORT with additional node types, that
describe a virtio-iommu.
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/Kc
ure
> > > > > to host iommu. VFIO exposes iommu programming capability to user-
> > > > > space. Guest is a user-space application in host under KVM solution.
> > > > > For SVA usage in Virtual Machine, guest owns GVA->GPA translation
> > >
Hi John,
On Mon, Nov 11, 2019 at 11:52:38AM +, John Garry wrote:
> On 11/11/2019 11:17, Jean-Philippe Brucker wrote:
> > Since commit 7723f4c5ecdb ("driver core: platform: Add an error message
> > to platform_get_irq*()"), platform_get_irq_byname() displays an err
t_irq()
returns -EPROBE_DEFER, which probably doesn't concern the SMMU.
Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
platform_get_irq*()")
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(
: IRQ priq not found
[ 20.718325] arm-smmu-v3 arm-smmu-v3.7.auto: IRQ gerror not found
Use platform_get_irq_byname_optional() to avoid displaying a spurious
error.
Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
platform_get_irq*()")
Signed-off-by: Jean-Philippe Brucker
s not
worth the hassle since they are managed resources.
Reviewed-by: Eric Auger
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-
.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 88ec0bf33492..3ee313c08325 100644
--- a/drivers/iommu/arm-smmu
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
pporting a SSID-capable device that is in
the same IOMMU group as a bridge, for example. Varying SSID size is less
of a concern, since the PCIe specification "highly recommends" that
devices supporting PASID implement all 20 bits of it.
Signed-off-by: Jean-Philippe Brucker
---
drivers
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 |
escriptor table for now, but as with
stream and page tables, an SSID can be split to index multiple levels of
tables.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 132 ++--
1 file changed, 111 insertions(+), 21 deletions(-)
diff --git a/d
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
---
Documentation/devicetree
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
omments.
[1]
https://lore.kernel.org/linux-iommu/20190610184714.6786-1-jean-philippe.bruc...@arm.com/
[2]
https://lore.kernel.org/linux-iommu/1572331216-9503-1-git-send-email-zhangfei@linaro.org/
[3]
https://lore.kernel.org/linux-iommu/1570045363-24856-1-git-send-email-jacob.jun@linux.intel.c
On Thu, Nov 07, 2019 at 09:23:50PM +0800, zhangfei wrote:
> > What I had in mind is keep one uacce_mm per mm and per device, and we can
> > pass that to iommu_sva_bind_device(). It requires some structure changes,
> > see the attached patch.
> Cool, thanks Jean
> How about merge them together.
No
On Wed, Nov 06, 2019 at 10:11:55PM -0800, Saravana Kannan wrote:
> > Right, in short the fundamental problem is that of_iommu_configure() now
> > does the wrong thing. Deferring probe of the entire host bridge/root
> > complex based on "iommu-map" would indeed happen to solve the problem by
> > bru
a_unbind_device() here since it will
be done by fops_release(), but then disabling the SVA feature in
uacce_unregister() won't work (because there still are bonds). The
attached patch should fix it, but I haven't tried running uacce_register()
yet.
Thanks,
Jean
>From 49559efc5cb26aadbcf580de03afd6e4ff67cedc M
Hi Zhangfei,
Thanks for simplifying this, it's a lot easier to review. I have some
additional comments.
On Tue, Oct 29, 2019 at 02:40:15PM +0800, Zhangfei Gao wrote:
> +static int uacce_sva_exit(struct device *dev, struct iommu_sva *handle,
> + void *data)
> +{
> + struc
mmu virtio0: device removed
$ modprobe virtio-iommu
[ 34.828982] virtio_iommu virtio0: input address: 64 bits
[ 34.829442] virtio_iommu virtio0: page mask: 0xf000
[ 34.844576] virtio-pci :00:03.0: Adding to iommu group 0
[ 34.916449] e1000e :00:02.0: Adding to iommu g
Hi Will,
On Fri, Nov 01, 2019 at 05:21:46PM +, Will Deacon wrote:
> As far as symbols exported from the IOMMU and PCI layers, did you find you
> needed anything on top of the stuff I'm exporting in patches 1 and 3?
No, I needed the same symbols (minus fsl_mc_device_group and
iommu_group_ref_g
On Thu, Oct 31, 2019 at 04:34:14PM -0700, Saravana Kannan wrote:
> > Neat, I'm trying to do the same for virtio-iommu. It needs to be modular
> > because it depends on the virtio transport, which distributions usually
> > build as a module. So far I've been managing the device links in
> > virtio-i
Hi Saravana, Will,
On Wed, Oct 30, 2019 at 05:57:44PM -0700, Saravana Kannan via iommu wrote:
> > > > Obviously you need to be careful about using IOMMU drivers as modules,
> > > > since late loading of the driver for an IOMMU serving active DMA masters
> > > > is going to end badly in many cases.
On Mon, Oct 14, 2019 at 10:14:05AM -0700, Jacob Pan wrote:
> Hi Joerg,
>
> Just another gentle reminder. I think we have reached consensus in this
> common code. Jean and Eric can confirm.
Yes for the whole series
Reviewed-by: Jean-Phil
allocators can share the same set of alloc()/free() helpers, in
> this case they also share the same IOASID space, thus the same XArray.
> - switching between allocators requires all outstanding IOASIDs to be
> freed unless the two allocators share the same alloc()/free() helpers.
>
&
Hi Jacob,
I have four tiny comments below but the patch looks great otherwise, no
major concern from me.
On Sat, Sep 21, 2019 at 05:07:49PM -0700, Jacob Pan wrote:
> +/*
> + * struct ioasid_allocator_data - Internal data structure to hold information
> + * about an allocator. There are two types
Hi Jacob,
There seem to be a mix-up here, the changes from your v2 are lost and
patches 1 and 3 are back to v1. Assuming this isn't intended, I'll
review v2 of this patch since it looked good to me overall.
Thanks,
Jean
___
iommu mailing list
iommu@lis
le address space per device, with two stages of
translation. I think it would work, although it would look better with
something like "PGD" instead of "PASID" in the API names (e.g.
iommu_sva_bind_gpgd) since that case wouldn't use PASID at all. But I
don't wan
On Wed, Sep 18, 2019 at 04:26:33PM -0700, Jacob Pan wrote:
> +/*
> + * struct ioasid_allocator_data - Internal data structure to hold information
> + * about an allocator. There are two types of allocators:
> + *
> + * - Default allocator always has its own XArray to track the IOASIDs
> allocated.
On Wed, Sep 18, 2019 at 04:26:32PM -0700, Jacob Pan wrote:
> From: Jean-Philippe Brucker
>
> Some devices might support multiple DMA address spaces, in particular
> those that have the PCI PASID feature. PASID (Process Address Space ID)
> allows to share process address spaces wi
re proposed here,
> model specific IOMMU drivers need to convert them into their own format.
>
> Signed-off-by: Yi L Liu
> Signed-off-by: Jacob Pan
> Signed-off-by: Ashok Raj
> Signed-off-by: Eric Auger
> Signed-off-by: Jean-Philippe Brucker
I tried to take a fresh look at
On Fri, Sep 20, 2019 at 08:07:38AM +0800, Guo Ren wrote:
> On Thu, Sep 19, 2019 at 11:18 PM Jean-Philippe Brucker
> wrote:
>
> >
> > The SMMU does support PCI Virtual Function - an hypervisor can assign a
> > VF to a guest, and let that guest partition the VF into sm
On Thu, Sep 19, 2019 at 09:07:15PM +0800, Guo Ren wrote:
> > The solution I had to this problem is pinning the ASID [1] used by the
> > IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
> > the CPU doesn't have to wait for IOMMU invalidations to complete, when
> > scheduling a
On Mon, Jul 08, 2019 at 09:58:16AM +0200, Auger Eric wrote:
> > + ret = pci_enable_pasid(pdev, features);
> > + if (!ret)
> > + master->ssid_bits = min_t(u8, ilog2(num_pasids),
> > + master->smmu->ssid_bits);
> I don't really get why this setting is
801 - 900 of 1703 matches
Mail list logo
