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 seque
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 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, perhaps
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.
>>
>> 1.mmap(4GB,MAP
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
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, f
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, 1
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
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 a/drivers/iommu/io-pgtable-
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 a/drivers/iommu/io-pgta
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 i
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 imp
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 io-pgtabl
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
---
drivers/iommu/
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 i
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 io-pgtab
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 fi
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 mapp
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
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. Instea
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 changed
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 Came
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?
>>
>>
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 th
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:
>
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 o
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(+), 2
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
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 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: Keq
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 b212bf0261820b..9a4cda3
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 a/drivers/iommu/iommu.
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 a/drivers/iommu/fsl_
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
Acked-by:
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 ++
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 b
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
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 a/drivers/iommu/fsl_pamu_do
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
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 ++
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 unuse
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(+), 16
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 58d1d11a8d5c10..052cef11a
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
---
drivers/iommu/fsl_pa
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
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 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 use
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 --
includ
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 deletions(
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 --
drivers/vho
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(+), 6
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 ch
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 --g
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 iommu_p
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() cal
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
for
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
ta
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 cal
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 pa
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
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 a/drive
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
---
.../devicetree/bindings/io
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
---
drivers/iommu/arm/arm-smmu-v3/arm
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 deletio
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
IOMMU_DE
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 imple
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: Jean-Ph
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 Aug
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 not
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 framewo
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 c
> 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 capabiliti
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 -
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 wo
> 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, bu
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
> 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 t
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
_
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; k
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 PAS
> 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
> -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; m...
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
Signed-off-b
On Thu, Apr 01, 2021 at 02:05:00PM +0200, Jean-Philippe Brucker wrote:
> On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> > > - how about AMD and ARM's vSVA support? Their PASID allocation and page
> > > table
> > > happens within guest. They only need to bind the guest PASID table to
Hi Zenghui,
On 4/1/21 8:11 AM, Zenghui Yu wrote:
> 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_
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> > - how about AMD and ARM's vSVA support? Their PASID allocation and page
> > table
> > happens within guest. They only need to bind the guest PASID table to
> > host.
In this case each VM has its own IOASID space, and the host IOASID
On Thu, Apr 01, 2021 at 07:04:01AM +, Liu, Yi L wrote:
> After reading your reply in
> https://lore.kernel.org/linux-iommu/20210331123801.gd1463...@nvidia.com/#t
> So you mean /dev/ioasid FD is per-VM instead of per-ioasid, so above skeleton
> doesn't suit your idea.
You can do it one PASID
Hi Zenghui,
On 3/30/21 11:23 AM, Zenghui Yu wrote:
> Hi Eric,
>
> On 2021/2/24 4:56, Eric Auger wrote:
>> In preparation for vSVA, let's accept userspace provided configs
>> with more than one CD. We check the max CD against the host iommu
>> capability and also the format (linear versus 2 level)
On Thu, Apr 01, 2021 at 04:38:44AM +, Liu, Yi L wrote:
> > 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
> > > the VM should b
On 2021-04-01 10:39, Geert Uytterhoeven wrote:
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
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
https://lists.linuxfoundation.org/mailman/listinfo/i
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 compa
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 (ext_as
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 driver
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,
> > +
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:
>
> > -
1 - 100 of 106 matches
Mail list logo
