On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote:
> Introduce a PCI parameter that disables the automatic attachment of
> untrusted devices to their drivers.
You didn't document this new api anywhere :(
___
iommu mailing list
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Thursday, June 25, 2020 11:16 PM
> To: Song Bao Hua (Barry Song) ; h...@lst.de;
> m.szyprow...@samsung.com; w...@kernel.org;
> ganapatrao.kulka...@cavium.com; catalin.mari...@arm.com
> Cc:
Hi Fenghua,
On 2020/6/26 4:17, Fenghua Yu wrote:
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
Hi Fenghua,
On 2020/6/26 4:17, Fenghua Yu wrote:
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
On Thu Jun 25 20, Joerg Roedel wrote:
From: Joerg Roedel
Hi,
here is a patch-set to remove the usage of dev->archdata.iommu from
the IOMMU code in the kernel and replace its uses by the iommu per-device
private data field. The changes also remove the field entirely from
the architectures
Hi Fenghua,
On 2020/6/26 4:17, Fenghua Yu wrote:
"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".
Reviewed-by: Lu Baolu
Best regards,
baolu
Suggested-by: Thomas Gleixner
Signed-off-by:
Hi Fenghua,
On 2020/6/26 4:17, Fenghua Yu wrote:
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
Introduce a PCI parameter that disables the automatic attachment of
untrusted devices to their drivers.
Signed-off-by: Rajat Jain
---
Context:
I set out to implement the approach outlined in
https://lkml.org/lkml/2020/6/9/1331
https://lkml.org/lkml/2020/6/15/1453
But to my
device_attach() returning failure indicates a driver error
while trying to probe the device. In such a scenario, the PCI
device should still be added in the system and be visible to
the user.
This patch partially reverts:
commit ab1a187bba5c ("PCI: Check device_attach() return value always")
>Should NVIDIA_TEGRA194_SMMU be a separate value for smmu->model, perhaps? That
>way we avoid this somewhat odd check here.
NVIDIA haven't made any changes to arm,mmu-500. It is only used in different
topology. New model would be mis-leading here.
As suggested by Robin, It can just be moved to
>> + - nvdia,tegra194-smmu-500
>The -500 suffix here seems a bit redundant since there's no other type of SMMU
>in Tegra194, correct?
Yeah, there is only one type of SMMU supported in T194. It was added to be
synonymous with mmu-500. Can be removed.
-KR
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
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
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:
-
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
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
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
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
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:
-
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
"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
---
v2:
- Add this new patch per Thomas' comment.
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
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
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
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
>
On Thu, Jun 25, 2020 at 04:52:27PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Using atomic64_t can be quite expensive, so use unsigned long instead.
> This is safe because the write becomes visible atomically.
>
> Signed-off-by: Joerg Roedel
> ---
>
From: Joerg Roedel
Do not call atomic64_set() directly to update the domain page-table
root and use two new helper functions.
This makes it easier to implement additional work necessary when
the page-table is updated.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/iommu.c | 31
From: Joerg Roedel
Hi,
a previous discussion pointed out that using atomic64_t for that
purpose is a bit of overkill. This patch-set replaces it with unsigned
long and introduces some helpers first to make the change more easy.
Qian, can you please test these patches in your environment? You
From: Joerg Roedel
Using atomic64_t can be quite expensive, so use unsigned long instead.
This is safe because the write becomes visible atomically.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/amd_iommu_types.h | 2 +-
drivers/iommu/amd/iommu.c | 10 --
2 files
Hi Joerg,
On 2020/6/25 21:08, Joerg Roedel wrote:
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 --
On Thu, Jun 25, 2020 at 03:08:35PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> There are no users left, all drivers have been converted to use the
> per-device private pointer offered by IOMMU core.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/arm64/include/asm/device.h | 3 ---
> 1
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/arm64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm64/include/asm/device.h
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/exynos-iommu.c | 20 +--
.../media/platform/s5p-mfc/s5p_mfc_iommu.h| 4 +++-
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/msm_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/device.h
From: Joerg Roedel
The iommu private pointer is already used in the Mediatek IOMMU v1
driver, so move the dma_iommu_mapping pointer into 'struct
mtk_iommu_data' and do not use dev->archdata.iommu anymore.
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.h| 2 ++
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/ia64/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/ia64/include/asm/device.h
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/omap-iommu.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
From: Joerg Roedel
Remove the use of dev->archdata.iommu_domain and use the private
per-device pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu_domain.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Joerg Roedel
There are no users left, so remove the pointer and save some memory.
Signed-off-by: Joerg Roedel
---
arch/powerpc/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
.../gpu/drm/i915/selftests/mock_gem_device.c | 10 --
drivers/iommu/intel/iommu.c| 18
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-gart.c | 8
drivers/iommu/tegra-smmu.c | 8
2 files changed, 8 insertions(+), 8
From: Joerg Roedel
Remove the use of dev->archdata.iommu and use the private per-device
pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/rockchip-iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Joerg Roedel
There are no users left, all drivers have been converted to use the
per-device private pointer offered by IOMMU core.
Signed-off-by: Joerg Roedel
---
arch/arm/include/asm/device.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/include/asm/device.h
From: Joerg Roedel
Hi,
here is a patch-set to remove the usage of dev->archdata.iommu from
the IOMMU code in the kernel and replace its uses by the iommu per-device
private data field. The changes also remove the field entirely from
the architectures which no longer need it.
On PowerPC the
Hi Jacob,
On 2020/6/24 1:03, Jacob Pan wrote:
+int __iommu_sva_unbind_gpasid(struct iommu_domain *domain, struct device *dev,
+ struct iommu_gpasid_bind_data *data)
{
if (unlikely(!domain->ops->sva_unbind_gpasid))
return -ENODEV;
- return
On 2020/6/23 23:43, Jacob Pan wrote:
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
On 2020-06-25 08:43, Barry Song wrote:
Right now, smmu is using dma_alloc_coherent() to get memory to save queues
and tables. Typically, on ARM64 server, there is a default CMA located at
node0, which could be far away from node2, node3 etc.
with this patch, smmu will get memory from local numa
On 2020-06-25 08:43, Barry Song wrote:
This is useful for at least two scenarios:
1. ARM64 smmu will get memory from local numa node, it can save its
command queues and page tables locally. Tests show it can decrease
dma_unmap latency at lot. For example, without this patch, smmu on
node2 will
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 case but give warning if
address does not align with the mask. This
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 address. This patch checks and enforce
address to be page aligned, otherwise
Hi Tomasz,
On 2020-06-24 4:58 a.m., Tomasz Figa wrote:
> On Wed, Jun 24, 2020 at 1:54 PM Krzysztof Kozlowski wrote:
>>
>> On Wed, Jun 24, 2020 at 01:39:50PM +0200, Hans Verkuil wrote:
>>> Can someone from Samsung or someone who knows this SoC take a look at this
>>> series?
>>>
>>> This series
Ganapatrao Kulkarni has put some effort on making arm-smmu-v3 use local
memory to save command queues[1]. I also did similar job in patch
"iommu/arm-smmu-v3: allocate the memory of queues in local numa node"
[2] while not realizing Ganapatrao did that before.
But it seems it is much better to
Right now, smmu is using dma_alloc_coherent() to get memory to save queues
and tables. Typically, on ARM64 server, there is a default CMA located at
node0, which could be far away from node2, node3 etc.
with this patch, smmu will get memory from local numa node to save command
queues and page
This is useful for at least two scenarios:
1. ARM64 smmu will get memory from local numa node, it can save its
command queues and page tables locally. Tests show it can decrease
dma_unmap latency at lot. For example, without this patch, smmu on
node2 will get memory from node0 by calling
On 2020/6/23 23:43, 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. This is more
On 2020/6/23 23:43, Jacob Pan wrote:
From: Liu Yi L
Set proper masks to avoid invalid input spillover to reserved bits.
Acked-by: Lu Baolu
Best regards,
baolu
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
include/linux/intel-iommu.h | 4 ++--
1 file changed, 2 insertions(+),
On 2020/6/23 23:43, Jacob Pan wrote:
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.
Acked-by: Lu Baolu
Best regards,
baolu
Link:
On 2020/6/25 1:07, Jacob Pan wrote:
On Wed, 24 Jun 2020 14:54:49 +0800
Lu Baolu wrote:
Hi Jacob,
On 2020/6/24 1:03, Jacob Pan wrote:
IOMMU UAPI data has a user filled argsz field which indicates the
data length comes with the API call. User data is not trusted,
argsz must be validated based
59 matches
Mail list logo
