Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Tuesday, June 30, 2020 2:16 AM
> To: Prakhya, Sai Praneeth
> Cc: iommu@lists.linux-foundation.org; Christoph Hellwig ; Raj,
> Ashok ; Will Deacon ; Lu Baolu
> ; Mehta, Sohil ; Robin
> Murphy ; Jacob Pan
> Subject: Re: [PATCH V4
Hi Kevin,
On 6/30/20 2:19 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Sunday, June 28, 2020 8:34 AM
After a page request is handled, software must response the device which
raised the page request with the handling result. This is done through
the iommu ops.page_response if the request was rep
Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu:
> PASID is defined as a few different types in iommu including "int",
> "u32", and "unsigned int". To be consistent and to match with uapi
> definitions, define PASID and its variations (e.g. max PASID) as "u32".
> "u32" is also shorter and a little mo
Hi Kevin,
Thanks a lot for reviewing my patches.
On 6/30/20 2:01 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Sunday, June 28, 2020 8:34 AM
A pasid might be bound to a page table from a VM guest via the iommu
ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
on the physical
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
> name STANDARD_AXI_MODE, all the latest SoC extend the register more
> feature by different bits, for example: axi_mode, in_order_en, coherent_en
> and so on. So rename REG_
Hi Jerry,
On 7/1/20 4:06 AM, Jerry Snitselaar wrote:
Move Intel Kconfig and Makefile bits down into intel directory
with the rest of the Intel specific files.
Cc: Joerg Roedel
Cc: Lu Baolu
Reviewed-by: Lu Baolu
Best regards,
baolu
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kco
Hi Jacob,
On 7/1/20 1:34 AM, Jacob Pan wrote:
On Thu, 25 Jun 2020 18:10:43 +0800
Lu Baolu wrote:
Hi,
On 2020/6/23 23:43, Jacob Pan wrote:
For guest requested IOTLB invalidation, address and mask are
provided as part of the invalidation data. VT-d HW silently ignores
any address bits below t
30.06.2020 13:07, Marek Szyprowski пишет:
> On 21.06.2020 06:00, Dmitry Osipenko wrote:
>> В Fri, 19 Jun 2020 12:36:31 +0200
>> Marek Szyprowski пишет:
>>
>>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>>> function returns the number of the created entries in the DMA address
On 7/1/20 5:07 AM, Jacob Pan wrote:
From: Liu Yi L
For guest SVA usage, in order to optimize for less VMEXIT, guest request
of IOTLB flush also includes device TLB.
On the host side, IOMMU driver performs IOTLB and implicit devTLB
invalidation. When PASID-selective granularity is requested by
On 7/1/20 5:07 AM, Jacob Pan wrote:
From: Liu Yi L
Address information for device TLB invalidation comes from userspace
when device is directly assigned to a guest with vIOMMU support.
VT-d requires page aligned address. This patch checks and enforce
address to be page aligned, otherwise reserv
Hi Jacob,
On 7/1/20 5:07 AM, Jacob Pan wrote:
DevTLB flush can be used for both DMA request with and without PASIDs.
The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
usage.
This patch adds a check for PASID value such that devTLB flush with
PASID is used for SVA case. Thi
uire at kernel/locking/lockdep.c:4250
[ 9426.746477][ T3356] Read of size 8 at addr 0089df1a6f68 by task bash/3356
[ 9426.753601][ T3356]
[ 9426.755782][ T3356] CPU: 5 PID: 3356 Comm: bash Not tainted
5.8.0-rc3-next-20200630 #2
[ 9426.763687][ T3356] Hardware name: HPE Apollo 70
Move TLB timeout and spin count macros to header file to
allow using the same values from vendor specific implementations.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 3 ---
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/io
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Docum
Changes in v9:
Move TLB Timeout and spin count macros to arm-smmu.h header to share with
implementation.
Set minItems and maxItems for reg property when compatible contains
nvidia,tegra194-smmu.
Update commit message for NVIDIA implementation patch.
Fail single SMMU instance usage through NVIDIA
NVIDIA's Tegra194 SoC has three ARM MMU-500 instances.
It uses two of ARM MMU-500s together to interleave IOVA accesses
across them and must be programmed identically.
The third SMMU instance is used as a regular ARM MMU-500 and it
can either be programmed independently or identical to other
two AR
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 98 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
Signed-o
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with uapi
definitions, define PASID and its variations (e.g. max PASID) as "u32".
"u32" is also shorter and a little more explicit than "unsigned int".
No PASID type change
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this patch to initialize PASID value for a new mm.
include/linux/mm_types.h | 2 ++
kernel/fork.c
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and a kernel-user transition to notify the
hardware of new work. What if both the translation and transition overhead
could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD
ena
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the d
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.
The PASID is freed when the process exits (so no need to keep
reference counts on how many SVM devic
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in E
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v4:
- Change PASID type to u32 (Christoph)
v3:
- Change
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
Reviewed-by: Lu Baolu
---
v5:
- Reviewed by Lu Baolu
v2:
- Add this
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Modify
From: Peter Zijlstra
The flag is defined for the task to identify if the task has a valid
PASID. Its initial value is 0 when the task is forked/cloned. It will
be used shortly.
Signed-off-by: Peter Zijlstra
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
---
v2:
- Add this patch to defi
A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in the current thread's PASID MSR. The
#GP fault handler will initialize the MSR if a PASID has been allocated
for this process.
Decoding the user instruction is ugly and sets a bad architecture
pre
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify process
address space and direct responses to the right address space.
Signed-off-by: Fenghua Y
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses that can be handled by the IOMMUs in the system. Parse that
data from the IVRS header to provide aperture information for DMA
mappings and users of the iommu API.
Changes for V2:
- use limits in iommu_setup_dma_ops()
-
Add a check to enforce that I/O virtual addresses picked by iommu API
users stay within the domains geometry aperture.
Signed-off-by: Sebastian Ott
Cc: Benjamin Serebrin
Cc: Filippo Sironi
CR: https://code.amazon.com/reviews/CR-26408388
---
drivers/iommu/amd/iommu.c | 9 -
1 file chan
The IVRS ACPI table specifies maximum address sizes for i/o virtual
addresses that can be handled by the IOMMUs in the system. Parse that
data from the IVRS header so that it can be considered in limiting the
IO aperture (in subsequent patches).
Based on prior work by Marius Hillenbrand.
Link: h
The IVRS ACPI table specifies maximum address sizes for I/O virtual
addresses. When allocating new protection domains that perform
translation, propagate these limits as the domain's geometry / aperture.
Based on prior work by Marius Hillenbrand.
Signed-off-by: Sebastian Ott
Cc: Benjamin Serebri
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> There is nothing PCI bus specific in the of_msi_map_rid()
> implementation other than the requester ID tag for the input
> ID space. Rename requester ID to a more generic ID so that
> the translation code can be used by all busses that r
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> From: Laurentiu Tudor
>
> The existing bindings cannot be used to specify the relationship
> between fsl-mc devices and GIC ITSes.
> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
> msi-map property.
> In addition,
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> From: Diana Craciun
>
> of_msi_map_get_device_domain() is PCI specific but it need not be and
> can be easily changed to be bus agnostic in order to be used by other
> busses by adding an IRQ domain bus token as an input parameter.
>
>
On Fri, Jun 19, 2020 at 2:20 AM Lorenzo Pieralisi
wrote:
>
> Devices sitting on proprietary busses have a device ID space that
> is owned by the respective bus and related firmware bindings. In order
> to let the generic OF layer handle the input translations to
> an IOMMU id, for such busses the
From: Liu Yi L
For guest SVA usage, in order to optimize for less VMEXIT, guest request
of IOTLB flush also includes device TLB.
On the host side, IOMMU driver performs IOTLB and implicit devTLB
invalidation. When PASID-selective granularity is requested by the guest
we need to derive the equiva
Global pages support is removed from VT-d spec 3.0 for dev TLB
invalidation. This patch is to remove the bits for vSVA. Similar change
already made for the native SVA. See the link below.
Link: https://lkml.org/lkml/2019/8/26/651
Acked-by: Lu Baolu
Signed-off-by: Jacob Pan
---
drivers/iommu/int
For the unlikely use case where multiple aux domains from the same pdev
are attached to a single guest and then bound to a single process
(thus same PASID) within that guest, we cannot easily support this case
by refcounting the number of users. As there is only one SL page table
per PASID while we
Hi Baolu and all,
This is a series to address some of the issues we found in vSVA support.
Most of the patches deal with exception handling, we also removed some bits
that are not currently supported.
Many thanks to Kevin Tian's review.
Jacob & Yi
Changelog:
v2 Address reviews from Baolu
From: Liu Yi L
Address information for device TLB invalidation comes from userspace
when device is directly assigned to a guest with vIOMMU support.
VT-d requires page aligned address. This patch checks and enforce
address to be page aligned, otherwise reserved bits can be set in the
invalidation
DevTLB flush can be used for both DMA request with and without PASIDs.
The former uses PASID#0 (RID2PASID), latter uses non-zero PASID for SVA
usage.
This patch adds a check for PASID value such that devTLB flush with
PASID is used for SVA case. This is more efficient in that multiple
PASIDs can b
For guest requested IOTLB invalidation, address and mask are provided as
part of the invalidation data. VT-d HW silently ignores any address bits
below the mask. SW shall also allow such case but give warning if
address does not align with the mask. This patch relax the fault
handling from error to
From: Liu Yi L
Set proper masks to avoid invalid input spillover to reserved bits.
Acked-by: Lu Baolu
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
include/linux/intel-iommu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include
>> The driver intend to support up to 3 instances. It doesn't really mandate
>> that all three instances be present in same DT node.
>> Each mmio aperture in "reg" property is an instance here. reg =
>> , , ; The reg can have
>> all three or less and driver just configures based on reg and it wo
Move AMD Kconfig and Makefile bits down into the amd directory
with the rest of the AMD specific files.
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kconfig | 45 +-
drivers/iommu/Makefile | 5 +
This patchset imeplements the suggestion from Linus to move the
Kconfig and Makefile bits for AMD and Intel into their respective
directories.
v2: Rebase against v5.8-rc3. Dropped ---help--- changes from Kconfig as that was
dealt with in systemwide cleanup.
Jerry Snitselaar (2):
iommu/v
Move Intel Kconfig and Makefile bits down into intel directory
with the rest of the Intel specific files.
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kconfig| 86 +---
drivers/iommu/Makefile | 8 +---
drivers/io
On Tue, 16 Jun 2020, Suravee Suthikulpanit wrote:
> > > On 6/1/20 4:01 PM, Alexander Monakov wrote:
> > > > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> > > >
> > > > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches
> > > > > > resolves the issue. This is the earliest point
On Mon, Jun 29, 2020 at 02:15:16PM +0100, Robin Murphy wrote:
> On 2020-06-27 08:02, Christoph Hellwig wrote:
> > On Fri, Jun 26, 2020 at 01:54:12PM -0700, Jonathan Lemon wrote:
> > > On Fri, Jun 26, 2020 at 09:47:25AM +0200, Christoph Hellwig wrote:
> > > >
> > > > Note that this is somewhat urge
On 30/06/2020 18:16, Krishna Reddy wrote:
>> OK, well I see what you are saying, but if we intended to support all 3 for
>> Tegra194, then we should ensure all 3 are initialised correctly.
>
> The driver intend to support up to 3 instances. It doesn't really mandate
> that all three instances
On Mon, Jun 29, 2020 at 9:49 PM Rajat Jain wrote:
>
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice for attribu
On Tue, 30 Jun 2020 02:52:45 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Tuesday, June 30, 2020 7:05 AM
> >
> > On Fri, 26 Jun 2020 16:19:23 -0600
> > Alex Williamson wrote:
> >
> > > On Tue, 23 Jun 2020 10:03:53 -0700
> > > Jacob Pan wrote:
> > >
> > > > IOMMU UAPI is newly
On Thu, 25 Jun 2020 18:10:43 +0800
Lu Baolu wrote:
> Hi,
>
> On 2020/6/23 23:43, Jacob Pan wrote:
> > For guest requested IOTLB invalidation, address and mask are
> > provided as part of the invalidation data. VT-d HW silently ignores
> > any address bits below the mask. SW shall also allow such
>OK, well I see what you are saying, but if we intended to support all 3 for
>Tegra194, then we should ensure all 3 are initialised correctly.
The driver intend to support up to 3 instances. It doesn't really mandate that
all three instances be present in same DT node.
Each mmio aperture in "reg
On Thu, 25 Jun 2020 18:05:52 +0800
Lu Baolu wrote:
> Hi,
>
> On 2020/6/23 23:43, Jacob Pan wrote:
> > From: Liu Yi L
> >
> > Address information for device TLB invalidation comes from userspace
> > when device is directly assigned to a guest with vIOMMU support.
> > VT-d requires page aligned
>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>> IOVA accesses across them.
>> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
>> string for Tegra194 SoC SMMU topology.
>There is no description here of the 3rd SMMU that you mention below.
>I think t
On Tue, Jun 30, 2020 at 06:08:31PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Tue,
On 2020-06-30 02:03, Lu Baolu wrote:
Hi Robin,
On 6/29/20 7:56 PM, Robin Murphy wrote:
On 2020-06-27 04:15, Lu Baolu wrote:
The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:
- Creat
On 30/06/2020 17:32, Jon Hunter wrote:
> On 30/06/2020 17:23, Krishna Reddy wrote:
+struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
+*smmu) {
+ unsigned int i;
>>
+ for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
+ struct resource *res;
>>
On 30/06/2020 17:23, Krishna Reddy wrote:
>>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>>> +*smmu) {
>>> + unsigned int i;
>
>>> + for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
>>> + struct resource *res;
>>> +
>>> + res = platform_get_reso
>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>> +*smmu) {
>> +unsigned int i;
>> +for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
>> +struct resource *res;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, i);
>> +if
On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > > On Mon, Jun 29, 2
On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > > > Add a new (optional) f
On 30/06/2020 15:53, Robin Murphy wrote:
> On 2020-06-30 09:19, Jon Hunter wrote:
>>
>> On 30/06/2020 01:10, Krishna Reddy wrote:
>>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>>> IOVA accesses across them.
>>> Add NVIDIA implementation for dual ARM MMU-500s and add new co
On 2020-06-30 09:19, Jon Hunter wrote:
On 30/06/2020 01:10, Krishna Reddy wrote:
NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 SoC SMMU topology.
There is
On 6/30/20 7:07 AM, Christoph Hellwig wrote:
On Mon, Jun 29, 2020 at 05:18:38PM +0200, Daniel Borkmann wrote:
On 6/29/20 5:10 PM, Björn Töpel wrote:
On 2020-06-29 15:52, Daniel Borkmann wrote:
Ok, fair enough, please work with DMA folks to get this properly integrated and
restored then. Appli
On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
For devices that aren't described in the DSDT - IORT translations
are determined by their ACPI parent device. Do you see/Have you
found any issue with this approach ?
The spec says
On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > > Add a new (optional) field to denote the physical location of a device
> > > in the system, and expos
On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > Add a new (optional) field to denote the physical location of a device
> > in the system, and expose it in sysfs. This was discussed here:
> > https://lore.kernel.org/l
From: Joerg Roedel
At least the version in the header file to fix a compile warning about
the function being unused.
Reported-by: Borislav Petkov
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/amd_iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd
On 30/06/2020 13:13, Robin Murphy wrote:
> On 2020-06-30 09:37, Jon Hunter wrote:
>>
>> On 30/06/2020 01:10, Krishna Reddy wrote:
>>> Add global/context fault hooks to allow NVIDIA SMMU implementation
>>> handle faults across multiple SMMUs.
>>
>> Nit ... this is not just for NVIDIA, but this allo
On 2020-06-30 01:10, Krishna Reddy wrote:
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree
On 2020-06-30 09:37, Jon Hunter wrote:
On 30/06/2020 01:10, Krishna Reddy wrote:
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Nit ... this is not just for NVIDIA, but this allows anyone to add
custom global/context and fault hooks. So
On Tue, 2020-06-30 at 18:56 +0800, Yong Wu wrote:
> Hi Chao,
>
> This is also ok for me. Only two format nitpick.
>
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > Given the fact that we are adding more and more plat_data bool values,
> > it would make sense to use a u32 flags register a
On Tue, 2020-06-30 at 18:55 +0800, Yong Wu wrote:
> On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common for merging
> > several larbs into one larb. At
On Mon, 2020-06-29 at 12:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > MT8173 is different from other SoCs for MMU_CTRL register.
> > For mt8173, its bit9 is in_order_write_en and doesn't use its
> > default 1'b1.> For other SoCs, bit[12] represents victim_tlb_en f
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-
On Mon, 2020-06-29 at 12:16 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Some platforms(ex: mt6779) need to improve performance by setting
> > REG_MMU_WR_LEN register. And we can use WR_THROT_EN macro to control
> > whether we need to set the register. If the registe
Hi Chao,
This is also ok for me. Only two format nitpick.
On Mon, 2020-06-29 at 15:13 +0800, Chao Hao wrote:
> Given the fact that we are adding more and more plat_data bool values,
> it would make sense to use a u32 flags register and add the appropriate
> macro definitions to set and check for
On Mon, 2020-06-29 at 11:28 +0200, Matthias Brugger wrote:
>
> On 29/06/2020 09:13, Chao Hao wrote:
> > Add F_MMU_IN_ORDER_WR_EN and F_MMU_STANDARD_AXI_MODE_BIT definition
> > in MISC_CTRL register.
> > F_MMU_STANDARD_AXI_MODE_BIT:
> > If we set F_MMU_STANDARD_AXI_MODE_BIT(bit[3][19] = 0, not fo
On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice for
On 2020-06-30 11:09, Joerg Roedel wrote:
On Mon, Jun 29, 2020 at 05:29:36PM +0100, Robin Murphy wrote:
On 2020-06-29 13:11, Geert Uytterhoeven wrote:
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
dma-iommu.c:(.text+0x92e): un
On 2020-06-30 11:23, Jon Hunter wrote:
On 29/06/2020 23:49, Krishna Reddy wrote:
+ if (!nvidia_smmu->bases[0])
+ nvidia_smmu->bases[0] = smmu->base;
+
+ return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
Not critical -- just a nit: why not put the bases[0] in in
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already properly did all the
scaterlist related calls.
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
> > For devices that aren't described in the DSDT - IORT translations
> > are determined by their ACPI parent device. Do you see/Have you
> > found any issue with this approach ?
>
> The spec says "Describes the IO relationships b
On 29/06/2020 23:49, Krishna Reddy wrote:
>>> + if (!nvidia_smmu->bases[0])
>>> + nvidia_smmu->bases[0] = smmu->base;
>>> +
>>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
>
>> Not critical -- just a nit: why not put the bases[0] in init()?
>
> smmu->base
On Fri, Jun 05, 2020 at 12:00:25AM -0700, Jerry Snitselaar wrote:
> When include/uapi/linux/iommu.h was created it was never
> added to the file list in MAINTAINERS.
>
> Cc: Joerg Roedel
> Signed-off-by: Jerry Snitselaar
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
Applied, than
On 30/06/2020 01:10, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
>
> Signed-off-by: Krishna Reddy
> ---
>
On Tue, Jun 30, 2020 at 10:17:56AM +0200, Marek Szyprowski wrote:
> Move the recently added sg_table wrapper out of CONFIG_IOMMU_SUPPORT to
> let the client code copile also when IOMMU support is disabled.
>
> Fixes: 48530d9fab0d ("iommu: add generic helper for mapping sgtable objects")
> Signed-o
On Mon, Jun 29, 2020 at 05:29:36PM +0100, Robin Murphy wrote:
> On 2020-06-29 13:11, Geert Uytterhoeven wrote:
> > If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config):
> >
> > drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap':
> > dma-iommu.c:(.text+0x92e): undefined reference to `dma_pgp
On 21.06.2020 06:00, Dmitry Osipenko wrote:
> В Fri, 19 Jun 2020 12:36:31 +0200
> Marek Szyprowski пишет:
>
>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
>> function returns the number of the created entries in the DMA address
>> space. However the subsequent calls to the
>>
On Sun, Jun 28, 2020 at 08:08:43PM +0200, Maxime Ripard wrote:
> The flush_all_tlb call back can be called from an atomic context, so using
> readl_poll_timeout that embeds a udelay doesn't work.
>
> Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver")
> Signed-off-by: Maxime Ripard
Appl
On Thu, Jun 25, 2020 at 03:08:23PM +0200, Joerg Roedel wrote:
> Joerg Roedel (13):
> iommu/exynos: Use dev_iommu_priv_get/set()
> iommu/vt-d: Use dev_iommu_priv_get/set()
> iommu/msm: Use dev_iommu_priv_get/set()
> iommu/omap: Use dev_iommu_priv_get/set()
> iommu/rockchip: Use dev_iommu_p
On Fri, Jun 26, 2020 at 08:30:21AM -0400, Qian Cai wrote:
> BTW, from the previous discussion, Linus mentioned,
>
> “
> The thing is, the 64-bit atomic reads/writes are very expensive on
> 32-bit x86. If it was just a native pointer, it would be much cheaper
> than an "atomic64_t".
> “
>
> Howev
On Wed, Jun 17, 2020 at 12:04:20AM +0200, Paul Menzel wrote:
> drivers/iommu/amd_iommu_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.
On Tue, Jun 16, 2020 at 04:47:14PM +0200, Jean-Philippe Brucker wrote:
> Some PCIe devices do not expect a PASID value in PRI Page Responses.
> If the "PRG Response PASID Required" bit in the PRI capability is zero,
> then the OS should not set the PASID field. Similarly on Arm SMMU,
> responses to
Hi Jerry,
On Fri, Jun 12, 2020 at 04:10:59PM -0700, Jerry Snitselaar wrote:
> Move Intel Kconfig and Makefile bits down into intel directory
> with the rest of the Intel specific files.
>
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Jerry Snitselaar
> ---
> drivers/iommu/Kconfig
1 - 100 of 122 matches
Mail list logo
