Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
With nested stage support, soon we will need to invalidate
S1 contexts and ranges tagged with an unmanaged asid, this
latter being managed by the guest. So let's introduce 2 helpers
that allow to invalidate with externally managed ASIDs
On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
> DMA page faults are delivered to root-complex via page request message and
> it is per-device according to PCIe spec. Page request handling flow is:
>
> 1) iommu driver receives a page request from device
> 2) iommu driver parses the
On Thu, Apr 01, 2021 at 11:59:45AM +0200, Christoph Hellwig wrote:
> For now I'll just pass the iommu_domain to iommu_get_dma_strict,
> so that we can check for it. We can do additional cleanups on top
> of that later.
Sounds good to me, cheers!
Will
Rather than have separate opaque setter functions that are easy to
overlook and lead to repetitive boilerplate in drivers, let's pass the
relevant initialisation parameters directly to iommu_device_register().
Acked-by: Will Deacon
Signed-off-by: Robin Murphy
---
v2: Add some kerneldoc and an
It happens that the 3 drivers which first supported being modular are
also ones which play games with their pgsize_bitmap, so have non-const
iommu_ops where dynamically setting the owner manages to work out OK.
However, it's less than ideal to force that upon all drivers which want
to be modular -
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:43 PM
>
> On Thu, Apr 01, 2021 at 01:38:46PM +, Liu, Yi L wrote:
> > > From: Jean-Philippe Brucker
> > > Sent: Thursday, April 1, 2021 8:05 PM
> > [...]
> > >
> > > Also wondering about:
> > >
> > > * Querying IOMMU nesting
On 2021-03-31 04:00, Isaac J. Manjarres wrote:
When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
the buffer at a granule of the largest page size that is supported by
the IOMMU hardware and fits within the buffer. For every block that
is unmapped, the IOMMU framework will
On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 7:47 PM
> [...]
> > I'm worried Intel views the only use of PASID in a guest is with
> > ENQCMD, but that is not consistent with the industry. We need to see
> > normal nested
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 9:16 PM
>
> On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 1, 2021 7:47 PM
> > [...]
> > > I'm worried Intel views the only use of PASID in a guest is with
> > > ENQCMD,
On Thu, Apr 01, 2021 at 04:34:37PM +0100, Robin Murphy wrote:
> On 2021-03-31 04:00, Isaac J. Manjarres wrote:
> > The IOMMU framework currently unmaps memory one page block at a time,
> > per the page block sizes that are supported by the IOMMU hardware.
> > Now that IOMMU drivers can supply a
> From: Jason Gunthorpe
> Sent: Thursday, April 1, 2021 7:47 PM
[...]
> I'm worried Intel views the only use of PASID in a guest is with
> ENQCMD, but that is not consistent with the industry. We need to see
> normal nested PASID support with assigned PCI VFs.
I'm not quire flow here. Intel also
On Thu, Apr 01, 2021 at 01:38:46PM +, Liu, Yi L wrote:
> > From: Jean-Philippe Brucker
> > Sent: Thursday, April 1, 2021 8:05 PM
> [...]
> >
> > Also wondering about:
> >
> > * Querying IOMMU nesting capabilities before binding page tables (which
> > page table formats are supported?). We
On 2021-03-31 04:00, Isaac J. Manjarres wrote:
The IOMMU framework currently unmaps memory one page block at a time,
per the page block sizes that are supported by the IOMMU hardware.
Now that IOMMU drivers can supply a callback for unmapping multiple
in one call, add support in the IOMMU
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 01 April 2021 12:49
> To: yuzenghui
> Cc: eric.auger@gmail.com; iommu@lists.linux-foundation.org;
> linux-ker...@vger.kernel.org; k...@vger.kernel.org;
> kvm...@lists.cs.columbia.edu; w...@kernel.org;
On Thu, Apr 01, 2021 at 01:43:36PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 1, 2021 9:16 PM
> >
> > On Thu, Apr 01, 2021 at 01:10:48PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, April 1, 2021 7:47 PM
> > > [...]
> > > > I'm
> From: Jean-Philippe Brucker
> Sent: Thursday, April 1, 2021 8:05 PM
[...]
>
> Also wondering about:
>
> * Querying IOMMU nesting capabilities before binding page tables (which
> page table formats are supported?). We were planning to have a VFIO cap,
> but I'm guessing we need to go back
Copy the "Stall supported" bit, that tells whether a named component
supports stall, into the dma-can-stall device property.
Acked-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Some systems allow devices to handle I/O Page Faults in the core mm. For
example systems implementing the PCIe PRI extension or Arm SMMU stall
model. Infrastructure for reporting these recoverable page faults was
added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
fault report
The SMMU provides a Stall model for handling page faults in platform
devices. It is similar to PCIe PRI, but doesn't require devices to have
their own translation cache. Instead, faulting transactions are parked
and the OS is given a chance to fix the page tables and retry the
transaction.
Enable
Add stall support to the SMMUv3 driver, along with a common I/O Page
Fault handler.
Since [v13] I added review and ack tags (Thanks!), and a lockdep_assert.
It would be good to have all of it in v5.13, since patch 10 introduces
the first user for the IOPF interface from patch 6. But if that's
The pasid-num-bits property shouldn't need a dedicated fwspec field,
it's a job for device properties. Add properties for IORT, and access
the number of PASID bits using device_property_read_u32().
Suggested-by: Robin Murphy
Acked-by: Jonathan Cameron
Acked-by: Will Deacon
Reviewed-by: Eric
Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
dev_iommu") removed iommu_priv from fwspec and commit 5702ee24182f
("ACPI/IORT: Check ATS capability in root complex nodes") added @flags.
Update the struct doc.
Acked-by: Jonathan Cameron
Acked-by: Will Deacon
Signed-off-by:
Some devices manage I/O Page Faults (IOPF) themselves instead of relying
on PCIe PRI or Arm SMMU stall. Allow their drivers to enable SVA without
mandating IOMMU-managed IOPF. The other device drivers now need to first
enable IOMMU_DEV_FEAT_IOPF before enabling IOMMU_DEV_FEAT_SVA. Enabling
The IOPF (I/O Page Fault) feature is now enabled independently from the
SVA feature, because some IOPF implementations are device-specific and
do not require IOMMU support for PCIe PRI or Arm SMMU stall.
Enable IOPF unconditionally when enabling SVA for now. In the future, if
a device driver
When handling faults from the event or PRI queue, we need to find the
struct device associated with a SID. Add a rb_tree to keep track of
SIDs.
Acked-by: Jonathan Cameron
Reviewed-by: Eric Auger
Reviewed-by: Keqian Zhu
Signed-off-by: Jean-Philippe Brucker
---
Allow drivers to query and enable IOMMU_DEV_FEAT_IOPF, which amounts to
checking whether PRI is enabled.
Reviewed-by: Lu Baolu
Signed-off-by: Jean-Philippe Brucker
---
Cc: David Woodhouse
Cc: Lu Baolu
---
drivers/iommu/intel/iommu.c | 11 ---
1 file changed, 8 insertions(+), 3
On ARM systems, some platform devices behind an IOMMU may support stall,
which is the ability to recover from page faults. Let the firmware tell us
when a device supports stall.
Reviewed-by: Eric Auger
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
---
Hi Shameer,
On 4/1/21 2:38 PM, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: 01 April 2021 12:49
>> To: yuzenghui
>> Cc: eric.auger@gmail.com; iommu@lists.linux-foundation.org;
>> linux-ker...@vger.kernel.org;
The snoop_id is always set to ~(u32)0.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 5 ++---
drivers/iommu/fsl_pamu_domain.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c
The only domains allocated forces use of a single window. Remove all
the code related to multiple window support, as well as the need for
qman_portal to force a single window.
Remove the now unused DOMAIN_ATTR_WINDOWS iommu_attr.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Merge the two fuctions that configure the ppaace into a single coherent
function. I somehow doubt we need the two pamu_config_ppaace calls,
but keep the existing behavior just to be on the safe side.
Signed-off-by: Christoph Hellwig
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 65
No good reason to split this functionality over two functions.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 59 +++--
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git
Remove the now unused iommu attr infrastructure.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
---
drivers/iommu/iommu.c | 26 --
include/linux/iommu.h | 36
2 files changed, 62 deletions(-)
diff --git
DOMAIN_ATTR_PAGING is never used.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/iommu.c | 5 -
include/linux/iommu.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index
Extend the calculation of 'count' in iommu_pgsize() so that it takes
larger page sizes into consideration and returns a value which will
allow a larger page size to be used on the next call.
Signed-off-by: Will Deacon
---
drivers/iommu/iommu.c | 36
1 file
Extend iommu_pgsize() to populate an optional 'count' paramater so that
we can direct unmapping operation to the ->unmap_pages callback if it
has been provided by the driver.
Signed-off-by: Will Deacon
---
drivers/iommu/iommu.c | 26 --
1 file changed, 20 insertions(+),
Hi Isaac,
I had a go at removing the loop you have in pgsize_bitmap() over at:
https://lore.kernel.org/r/20210331030042.13348-4-isa...@codeaurora.org
and I ended up with this. It's _very_ lightly tested, but I thought it
might be useful to you, especially if you're going to be adding support
From: "Isaac J. Manjarres"
The io-pgtable code expects to operate on a single block or
granule of memory that is supported by the IOMMU hardware when
unmapping memory.
This means that when a large buffer that consists of multiple
such blocks is unmapped, the io-pgtable code will walk the page
From: "Isaac J. Manjarres"
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can call
into the io-pgtable code, to unmap a virtually contiguous
range of pages of the same size.
For IOMMU drivers that do not specify an unmap_pages()
The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
intended to describe the alignment requirements to consider when
choosing an appropriate page size. On the iommu_map() path, this address
is the logical OR of the virtual and physical addresses.
Subsequent improvements to
Avoid the potential for shifting values by amounts greater than the
width of their type by using a bitmap to compute page size in
iommu_pgsize().
Signed-off-by: Will Deacon
---
drivers/iommu/iommu.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff
On Thu, Apr 01, 2021 at 05:47:16PM +0200, Jean-Philippe Brucker wrote:
> When handling faults from the event or PRI queue, we need to find the
> struct device associated with a SID. Add a rb_tree to keep track of
> SIDs.
>
> Acked-by: Jonathan Cameron
> Reviewed-by: Eric Auger
> Reviewed-by:
On 4/1/21 10:33 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 30, 2021 at 07:36:07AM +0200, Christoph Hellwig wrote:
>> On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote:
>>> Should I toss this in Russell's patch tracker or do you need me to make
>>> some changes to the patch?
>>
Use an explicit set_pgtable_quirks method instead that just passes
the actual quirk bitmask instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 +-
drivers/iommu/arm/arm-smmu/arm-smmu.c | 64
The default geometry is the same as the one set by qman_port given
that FSL_PAMU depends on having 64-bit physical and thus DMA addresses.
Remove the support to update the geometry and remove the now pointless
geom_size field.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li
Instead of a separate call to enable all devices from the list, just
enable the liodn once the device is attached to the iommu domain.
This also remove the DOMAIN_ATTR_FSL_PAMU_ENABLE iommu_attr.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
Use an explicit enable_nesting method instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 43 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 30 +++---
drivers/iommu/intel/iommu.c
From: Robin Murphy
Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.
This make sure that the iommu.strict parameter also works for the AMD and
Intel IOMMU drivers on x86. As those default to lazy
Add a fsl_pamu_configure_l1_stash API that qman_portal can call directly
instead of indirecting through the iommu attr API.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
arch/powerpc/include/asm/fsl_pamu_stash.h | 12 +++-
drivers/iommu/fsl_pamu_domain.c
Hi all,
there are a bunch of IOMMU APIs that are entirely unused, or only used as
a private communication channel between the FSL PAMU driver and it's only
consumer, the qbman portal driver.
So this series drops a huge chunk of entirely unused FSL PAMU
functionality, then drops all kinds of
The win_addr and win_size parameters are always set to 0 and 1 << 36
respectively, so just hard code them.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/fsl_pamu.c| 23 ---
drivers/iommu/fsl_pamu.h| 3 +--
drivers/iommu/fsl_pamu_domain.c | 10 ++
Don't obsfucate the trivial bit flag check.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
---
drivers/iommu/iommu.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index
These are always wired to fixed values, so don't bother passing them as
arguments.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/fsl_pamu.c| 14 +++---
drivers/iommu/fsl_pamu.h| 3 +--
drivers/iommu/fsl_pamu_domain.c | 6 +++---
3 files changed, 7 insertions(+),
Keep the functionality to allocate the domain together.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 34 ++---
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git
On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote:
> Add stall support to the SMMUv3 driver, along with a common I/O Page
> Fault handler.
>
> Since [v13] I added review and ack tags (Thanks!), and a lockdep_assert.
> It would be good to have all of it in v5.13, since patch 10
Hi Jason,
On Wed, 31 Mar 2021 21:37:05 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 31, 2021 at 04:46:21PM -0700, Jacob Pan wrote:
> > Hi Jason,
> >
> > On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe
> > wrote:
> > > > > Get rid of the ioasid set.
> > > > >
> > > > > Each driver has its
On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote:
> The SMMU provides a Stall model for handling page faults in platform
> devices. It is similar to PCIe PRI, but doesn't require devices to have
> their own translation cache. Instead, faulting transactions are parked
> and the
On 2021-03-31 04:00, Isaac J. Manjarres wrote:
Implement the unmap_pages() callback for the ARM LPAE io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
drivers/iommu/io-pgtable-arm.c | 114 +++--
1 file changed, 94 insertions(+),
On Thu, Apr 01, 2021 at 10:23:55AM -0700, Jacob Pan wrote:
> Hi Jason,
>
> On Wed, 31 Mar 2021 21:37:05 -0300, Jason Gunthorpe wrote:
>
> > On Wed, Mar 31, 2021 at 04:46:21PM -0700, Jacob Pan wrote:
> > > Hi Jason,
> > >
> > > On Wed, 31 Mar 2021 09:38:01 -0300, Jason Gunthorpe
> > > wrote:
On Tue, Mar 30, 2021 at 07:36:07AM +0200, Christoph Hellwig wrote:
> On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote:
> > Should I toss this in Russell's patch tracker or do you need me to make
> > some changes to the patch?
>
> Due to all the other changes in this area I don't
None of the values returned by this function are ever queried. Also
remove the DOMAIN_ATTR_FSL_PAMUV1 enum value that is not otherwise used.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 30 --
The only thing that fsl_pamu_window_enable does for the current caller
is to fill in the prot value in the only dma_window structure, and to
propagate a few values from the iommu_domain_geometry struture into the
dma_window. Remove the dma_window entirely, hardcode the prot value and
otherwise
The geometry information can be trivially queried from the iommu_domain
struture.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/iommu.c | 20 +++-
drivers/vfio/vfio_iommu_type1.c | 26 --
domain_window_disable is wired up by fsl_pamu, but never actually called.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Li Yang
---
drivers/iommu/fsl_pamu_domain.c | 48 -
include/linux/iommu.h | 2 --
2 files changed, 50
On 2021/4/1 23:47, Jean-Philippe Brucker wrote:
The pasid-num-bits property shouldn't need a dedicated fwspec field,
it's a job for device properties. Add properties for IORT, and access
the number of PASID bits using device_property_read_u32().
Suggested-by: Robin Murphy
Acked-by: Jonathan
On 2021/4/1 23:47, Jean-Philippe Brucker wrote:
Copy the "Stall supported" bit, that tells whether a named component
supports stall, into the dma-can-stall device property.
Acked-by: Jonathan Cameron
Signed-off-by: Jean-Philippe Brucker
---
drivers/acpi/arm64/iort.c | 4 +++-
1 file
From: Will Deacon
The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
intended to describe the alignment requirements to consider when
choosing an appropriate page size. On the iommu_map() path, this address
is the logical OR of the virtual and physical addresses.
Subsequent
When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
the buffer at a granule of the largest page size that is supported by
the IOMMU hardware and fits within the buffer. For every block that
is unmapped, the IOMMU framework will call into the IOMMU driver, and
then the
Implement the unmap_pages() callback for the ARM LPAE io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
drivers/iommu/io-pgtable-arm.c | 124 +++--
1 file changed, 104 insertions(+), 20 deletions(-)
diff --git
From: Will Deacon
Extend iommu_pgsize() to populate an optional 'count' paramater so that
we can direct unmapping operation to the ->unmap_pages callback if it
has been provided by the driver.
Signed-off-by: Will Deacon
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/iommu.c | 60
Implement the unmap_pages() callback for the ARM SMMU driver
to allow calls from iommu_unmap to unmap multiple pages of
the same size in one call.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 19 +++
1 file changed, 19
Implement the map_pages() callback for the ARM LPAE io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
drivers/iommu/io-pgtable-arm.c | 95 +++---
1 file changed, 88 insertions(+), 7 deletions(-)
diff --git
Since iommu_pgsize can calculate how many pages of the
same size can be mapped/unmapped before the next largest
page size boundary, add support for invoking an IOMMU
driver's map_pages() callback, if it provides one.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
The io-pgtable code expects to operate on a single block or
granule of memory that is supported by the IOMMU hardware when
unmapping memory.
This means that when a large buffer that consists of multiple
such blocks is unmapped, the io-pgtable code will walk the page
tables to the correct level to
Mapping memory into io-pgtables follows the same semantics
that unmapping memory used to follow (i.e. a buffer will be
mapped one page block per call to the io-pgtable code). This
means that it can be optimized in the same way that unmapping
memory was, so add a map_pages() callback to the
Implement the unmap_pages() callback for the ARM SMMU driver
to allow calls from iommu_unmap to unmap multiple pages of
the same size in one call.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Will Deacon
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 19 +++
1 file changed, 19
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can call
into the io-pgtable code, to unmap a virtually contiguous
range of pages of the same size.
For IOMMU drivers that do not specify an unmap_pages() callback,
the existing logic of
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can
call into the io-pgtable code, to map a physically contiguous
rnage of pages of the same size.
For IOMMU drivers that do not specify a map_pages() callback,
the existing logic of
From: Will Deacon
Avoid the potential for shifting values by amounts greater than the
width of their type by using a bitmap to compute page size in
iommu_pgsize().
Signed-off-by: Will Deacon
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/iommu.c | 31 ---
1
On 4/2/21 11:41 AM, Longpeng (Mike, Cloud Infrastructure Service Product
Dept.) wrote:
Hi Baolu,
在 2021/4/2 11:06, Lu Baolu 写道:
Hi Longpeng,
On 4/1/21 3:18 PM, Longpeng(Mike) wrote:
The translation caches may preserve obsolete data when the
mapping size is changed, suppose the following
Hi, Will
On 2021/4/2 上午1:11, Will Deacon wrote:
On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote:
The SMMU provides a Stall model for handling page faults in platform
devices. It is similar to PCIe PRI, but doesn't require devices to have
their own translation cache.
On 2021/4/2 1:11, Will Deacon wrote:
> On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote:
>> The SMMU provides a Stall model for handling page faults in platform
>> devices. It is similar to PCIe PRI, but doesn't require devices to have
>> their own translation cache. Instead,
On Tue, Mar 16, 2021 at 12:16:43PM +0100, Thierry Reding wrote:
> > +struct tegra_smmu_group_debug {
> > + const struct tegra_smmu_swgroup *group;
> > + void *priv;
>
> This always stores the address space, so why not make this:
>
> struct tegra_smmu_as *as;
>
> ? While at it,
Hi Baolu,
在 2021/4/2 11:06, Lu Baolu 写道:
> Hi Longpeng,
>
> On 4/1/21 3:18 PM, Longpeng(Mike) wrote:
>> The translation caches may preserve obsolete data when the
>> mapping size is changed, suppose the following sequence which
>> can reveal the problem with high probability.
>>
>>
Hi Longpeng,
On 4/1/21 3:18 PM, Longpeng(Mike) wrote:
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee09323..cbcb434 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2342,9 +2342,20 @@ static inline int hardware_largepage_caps(struct
On 2021-04-01 09:47, Will Deacon wrote:
Avoid the potential for shifting values by amounts greater than the
width of their type by using a bitmap to compute page size in
iommu_pgsize().
Signed-off-by: Will Deacon
---
drivers/iommu/iommu.c | 31 ---
1 file changed,
Hi Longpeng,
On 4/1/21 3:18 PM, Longpeng(Mike) wrote:
The translation caches may preserve obsolete data when the
mapping size is changed, suppose the following sequence which
can reveal the problem with high probability.
1.mmap(4GB,MAP_HUGETLB)
2.
while (1) {
(a)DMA MAP 0,0xa
Hi Eric,
On 2021/2/24 4:56, Eric Auger wrote:
+static int
+arm_smmu_cache_invalidate(struct iommu_domain *domain, struct device *dev,
+ struct iommu_cache_invalidate_info *inv_info)
+{
+ struct arm_smmu_cmdq_ent cmd = {.opcode = CMDQ_OP_TLBI_NSNH_ALL};
+
The translation caches may preserve obsolete data when the
mapping size is changed, suppose the following sequence which
can reveal the problem with high probability.
1.mmap(4GB,MAP_HUGETLB)
2.
while (1) {
(a)DMA MAP 0,0xa
(b)DMA UNMAP 0,0xa
(c)DMA MAP
Hi Jason,
> From: Liu, Yi L
> Sent: Thursday, April 1, 2021 12:39 PM
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 31, 2021 8:41 PM
> >
> > On Wed, Mar 31, 2021 at 07:38:36AM +, Liu, Yi L wrote:
> >
> > > The reason is /dev/ioasid FD is per-VM since the ioasid allocated to
> > >
On Tue, Mar 30, 2021 at 07:17:55PM +0200, Jean-Philippe Brucker wrote:
> On Tue, Mar 02, 2021 at 10:26:36AM +0100, Jean-Philippe Brucker wrote:
> > Add stall support to the SMMUv3 driver, along with a common I/O Page
> > Fault handler.
>
> I only have review/ack tags and one assert_lockdep to add
On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote:
> The previous commit fixes problem where display client was attaching too
> early to IOMMU during kernel boot in a multi-platform kernel configuration
> which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to
> defer
On Wed 2021-03-31 09:40:07, Steven Rostedt wrote:
> On Wed, 31 Mar 2021 11:31:03 +0200
> Geert Uytterhoeven wrote:
>
> > This reduces kernel size by ca. 0.5 KiB.
>
> If you are worried about size, disable tracing and it will go away
> entirely. 0.5KiB is a drop in the bucket compared to what
On Tue, Mar 30, 2021 at 01:58:17PM +0100, Will Deacon wrote:
> pamu_config_ppaace() takes quite a few useless parameters at this stage,
> but anyway:
I'll see it it makes sense to throw in another patch at the end to cut
it down a bit more.
> Acked-by: Will Deacon
>
> Do you know if this
Hi Zenghui,
On 3/30/21 11:17 AM, Zenghui Yu wrote:
> On 2021/2/24 4:56, Eric Auger wrote:
>> @@ -1936,7 +1950,12 @@ static void
>> arm_smmu_tlb_inv_range_domain(unsigned long iova, size_t size,
>> },
>> };
>> - if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1) {
>> + if
Hi Steven,
On Wed, Mar 31, 2021 at 3:40 PM Steven Rostedt wrote:
> On Wed, 31 Mar 2021 11:31:03 +0200
> Geert Uytterhoeven wrote:
>
> > This reduces kernel size by ca. 0.5 KiB.
>
> If you are worried about size, disable tracing and it will go away
> entirely. 0.5KiB is a drop in the bucket
On Tue, Mar 30, 2021 at 01:22:34PM +0100, Will Deacon wrote:
> > * win_arr contains information of the configured
> > * windows for a domain. This is allocated only
> > * when the number of windows for the domain are
> > * set.
> > */
>
> The last part of this comment is
On Tue, Mar 30, 2021 at 01:40:09PM +0100, Will Deacon wrote:
> > + ret = pamu_config_ppaace(liodn, geom->aperture_start,
> > +geom->aperture_end - 1, ~(u32)0,
>
> You're passing 'geom->aperture_end - 1' as the size here, but the old code
> seemed to _add_ 1:
>
> >
On Tue, Mar 30, 2021 at 01:46:51PM +0100, Will Deacon wrote:
> > + ret = pamu_config_ppaace(liodn, geom->aperture_start,
> > +geom->aperture_end - 1, ~(u32)0,
> > +0, dma_domain->snoop_id, dma_domain->stash_id,
> > +
For now I'll just pass the iommu_domain to iommu_get_dma_strict,
so that we can check for it. We can do additional cleanups on top
of that later.
___
iommu mailing list
iommu@lists.linux-foundation.org
1 - 100 of 107 matches
Mail list logo
