On Thu, Sep 10, 2020 at 01:55:37PM +0100, Robin Murphy wrote:
> AFAICS all three of these bus drivers are only proxying a struct
> dma_map_ops * pointer around, so if they used the set_dma_ops() helper they
> shouldn't even need these selects at all. Only INTEL_MIC_HOST appears to
> have a logic
On Tue, Sep 08, 2020 at 09:04:17PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 9/8/20 7:47 PM, Christoph Hellwig wrote:
>
> > Driver that select DMA_OPS need to depend on HAS_DMA support to
> > work. The vop driver was missing that dependency, so add it, and also
> > add a nother depends in DM
On Thu, Sep 10, 2020 at 02:26:03PM +0100, Robin Murphy wrote:
> On 2020-09-08 17:47, Christoph Hellwig wrote:
>> There is no harm in just always clearing the SME encryption bit, while
>> significantly simplifying the interface.
>
> After a 10-minute diversion into "but hang on, force_dma_unencrypte
On Thu, Sep 10, 2020 at 02:34:18PM +0100, Robin Murphy wrote:
> On 2020-09-08 17:47, Christoph Hellwig wrote:
>> Add a new file that contains helpera for misc DMA ops, which is only
>
> The Latin plural of the singular "helperum", I guess? :P
I've switched it to helpers, that might be easier to un
On Thu, Sep 10, 2020 at 02:51:47PM +0100, Robin Murphy wrote:
> On 2020-09-08 17:47, Christoph Hellwig wrote:
>> dma_declare_coherent_memory should not be in a DMA API guide aimed
>> at driver writers (that is consumers of the API). Move it to a comment
>> near the function instead.
>
> I still th
There can be clients using the same swgroup in DT, for example i2c0
and i2c1. The current driver will add them to separate IOMMU groups,
though it has implemented device_group() callback which is to group
devices using different swgroups like DC and DCB.
All clients having the same swgroup should
IOVA might not be always 4KB aligned. So tegra_smmu_iova_to_phys
function needs to add on the lower 12-bit offset from input iova.
Signed-off-by: Nicolin Chen
---
drivers/iommu/tegra-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/i
These are a series of small fixes for tegra-smmu driver.
They might not be critial bugs as current mainline does
not enable a lot of clients, but be nicer to have since
we are going to enable the DMA domain for other clients
in the near future.
Nicolin Chen (3):
iommu/tegra-smmu: Do not use PAGE
PAGE_SHIFT and PAGE_MASK are defined corresponding to the page size
for CPU virtual addresses, which means PAGE_SHIFT could be a number
other than 12, but tegra-smmu maintains fixed 4KB IOVA pages and has
fixed [21:12] bit range for PTE entries.
So this patch replaces all PAGE_SHIFT/PAGE_MASK refe
Hi Bjorn,
On 2020-09-04 21:25, Bjorn Andersson wrote:
Based on previous attempts and discussions this is the latest attempt
at
inheriting stream mappings set up by the bootloader, for e.g. boot
splash or
efifb.
Per Will's request this builds on the work by Jordan and Rob for the
Adreno
SMMU
On 2020-09-04 21:25, Bjorn Andersson wrote:
Extract the conditional invocation of the platform defined
alloc_context_bank() to a separate function to keep
arm_smmu_init_domain_context() cleaner.
Instead pass a reference to the arm_smmu_device as parameter to the
call. Also remove the count param
On 2020-09-04 21:25, Bjorn Andersson wrote:
Delay modifications to the domain during arm_smmu_init_domain_context()
until we've allocated a context bank. This will allow us to postpone
the
special handling of identity domains until the platform specific
context
bank allocator has been executed
On 2020-09-04 21:25, Bjorn Andersson wrote:
For implementations of the ARM SMMU where stream mappings of bypass
type
are prohibited identity domains can be implemented by using context
banks with translation disabled.
Postpone the decision to skip allocating a context bank until the
implementat
On 2020-09-04 21:25, Bjorn Andersson wrote:
For implementations of the ARM SMMU where stream mappings of bypass
type
are prohibited identity domains can be implemented by using context
banks with translation disabled.
Postpone the decision to skip allocating a context bank until the
implementat
On 2020-09-04 21:25, Bjorn Andersson wrote:
Some firmware found on various Qualcomm platforms traps writes to S2CR
of type BYPASS and writes FAULT into the register. In particular, this
prevents us from marking the streams for the display controller as
BYPASS to allow continued scanout of the scr
On 2020-09-04 21:25, Bjorn Andersson wrote:
Firmware that traps writes to S2CR to translate BYPASS into FAULT also
ignores writes of type FAULT. As such booting with "disable_bypass" set
will result in all S2CR registers left as configured by the bootloader.
This has been seen to result in indet
On 2020-09-04 21:25, Bjorn Andersson wrote:
Add a new operation to allow platform implementations to inherit any
stream mappings from the boot loader.
Signed-off-by: Bjorn Andersson
---
Reviewed-by: Sai Prakash Ranjan
Tested-by: Sai Prakash Ranjan
--
QUALCOMM INDIA, on behalf of Qualcomm
On 2020-09-04 21:25, Bjorn Andersson wrote:
Some platform implementations needs to be able to allocate a domain for
emulating identity mappings using a context bank without translation.
Provide a helper function to allocate such a domain.
Signed-off-by: Bjorn Andersson
---
Reviewed-by: Sai P
On 2020-09-04 21:25, Bjorn Andersson wrote:
With many Qualcomm platforms not having functional S2CR BYPASS a
temporary IOMMU domain, without translation, needs to be allocated in
order to allow these memory transactions.
Unfortunately the boot loader uses the first few context banks, so
rather t
ipmmu-vmsa driver is also used on Renesas RZ/G{1,2} Soc's, update the
same to reflect the help description for IPMMU_VMSA config.
Signed-off-by: Lad Prabhakar
Reviewed-by: Chris Paterson
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/
Fix IOVA reserve failure in the case when address of first memory region
listed in dma-ranges is equal to 0x0.
Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
address")
Signed-off-by: Srinath Mannam
---
Changes from v1:
Removed unnecessary changes based on Robin's rev
On 2020-09-10 06:40, Christoph Hellwig wrote:
The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t. Currently the code compiles fine despite that, a pending
change to the DMA offset handling would create
On 2020-09-11 12:15, Russell King - ARM Linux admin wrote:
On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t. Currently the code comp
On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
> The DMA offset notifier can only be used if PHYS_OFFSET is at least
> KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
> phys_addr_t. Currently the code compiles fine despite that, a pending
> change to the DMA of
kzfree() is effectively deprecated as of commit 453431a54934 ("mm,
treewide: rename kzfree() to kfree_sensitive()") and is now simply an
alias for kfree_sensitive(). So just replace it with kfree_sensitive().
Signed-off-by: Alex Dewar
---
drivers/iommu/fsl_pamu.c | 2 +-
1 file changed, 1 insert
Some hardware variants contain a system cache or the last level
cache(llc). This cache is typically a large block which is shared
by multiple clients on the SOC. GPU uses the system cache to cache
both the GPU data buffers(like textures) as well the SMMU pagetables.
This helps with improved render
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 7 ++-
include/linux/io-pgtable.h | 4
2 files changed, 10 insertions(+), 1 deletion
Add iommu domain attribute for using system cache aka last level
cache by client drivers like GPU to set right attributes for caching
the hardware pagetables into the system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 +
drivers/iommu/a
From: Sharat Masetty
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
Signed-off-by: Sai Prak
Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff
There are few places in arm-smmu-impl where there are
extra blank lines, remove them and while at it fix the
checkpatch warning for space required before the open
parenthesis.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 5 +
1 file changed, 1 insertion(
From: Sharat Masetty
The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire the
On Fri, Sep 11, 2020 at 03:55:34PM +0530, Srinath Mannam wrote:
> Fix IOVA reserve failure in the case when address of first memory region
> listed in dma-ranges is equal to 0x0.
>
> Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
> address")
> Signed-off-by: Srinath Mann
On 2020-09-11 15:28, Sai Prakash Ranjan wrote:
There are few places in arm-smmu-impl where there are
extra blank lines, remove them
FWIW those were deliberate - sometimes I like a bit of subtle space to
visually delineate distinct groups of definitions. I suppose it won't be
to everyone's tas
On Fri, Sep 11, 2020 at 05:03:06PM +0100, Robin Murphy wrote:
> BTW am I supposed to have received 3 copies of everything? Because I did...
Yeah, this seems to be happening for all of Sai's emails :/
Will
___
iommu mailing list
iommu@lists.linux-foundat
On Fri, 4 Sep 2020 at 21:25, Bjorn Andersson wrote:
>
> Based on previous attempts and discussions this is the latest attempt at
> inheriting stream mappings set up by the bootloader, for e.g. boot splash or
> efifb.
>
> Per Will's request this builds on the work by Jordan and Rob for the Adreno
>
(apologies to Jim - I did look through one of the previous versions
since I last commented and thought it looked OK, but never actually
replied as such)
On 2020-09-10 06:40, Christoph Hellwig wrote:
From: Jim Quinlan
The new field 'dma_range_map' in struct device is used to facilitate the
us
On 2020-09-11 21:33, Robin Murphy wrote:
On 2020-09-11 15:28, Sai Prakash Ranjan wrote:
There are few places in arm-smmu-impl where there are
extra blank lines, remove them
FWIW those were deliberate - sometimes I like a bit of subtle space to
visually delineate distinct groups of definitions.
On 2020-09-11 21:37, Will Deacon wrote:
On Fri, Sep 11, 2020 at 05:03:06PM +0100, Robin Murphy wrote:
BTW am I supposed to have received 3 copies of everything? Because I
did...
Yeah, this seems to be happening for all of Sai's emails :/
Sorry, I am not sure what went wrong as I only sent t
On 2020-09-11 17:21, Sai Prakash Ranjan wrote:
On 2020-09-11 21:37, Will Deacon wrote:
On Fri, Sep 11, 2020 at 05:03:06PM +0100, Robin Murphy wrote:
BTW am I supposed to have received 3 copies of everything? Because I
did...
Yeah, this seems to be happening for all of Sai's emails :/
Sorry
On 2020-09-11 22:04, Robin Murphy wrote:
On 2020-09-11 17:21, Sai Prakash Ranjan wrote:
On 2020-09-11 21:37, Will Deacon wrote:
On Fri, Sep 11, 2020 at 05:03:06PM +0100, Robin Murphy wrote:
BTW am I supposed to have received 3 copies of everything? Because I
did...
Yeah, this seems to be hap
On 2020-09-04 16:55, Bjorn Andersson wrote:
Add a new operation to allow platform implementations to inherit any
stream mappings from the boot loader.
Is there a reason we need an explicit step for this? The aim of the
cfg_probe hook is that the SMMU software state should all be set up by
the
On 2020-09-04 16:55, Bjorn Andersson wrote:
With many Qualcomm platforms not having functional S2CR BYPASS a
temporary IOMMU domain, without translation, needs to be allocated in
order to allow these memory transactions.
Unfortunately the boot loader uses the first few context banks, so
rather t
On 9/11/20 4:15 AM, Russell King - ARM Linux admin wrote:
On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t. Currently the code compi
On Thu, 10 Sep 2020 03:45:18 -0700
Liu Yi L wrote:
> IOMMUs that support nesting translation needs report the capability info
> to userspace. It gives information about requirements the userspace needs
> to implement plus other features characterizing the physical implementation.
>
> This patch
On Thu, 10 Sep 2020 03:45:20 -0700
Liu Yi L wrote:
> This patch exports iommu nesting capability info to user space through
> VFIO. Userspace is expected to check this info for supported uAPIs (e.g.
> PASID alloc/free, bind page table, and cache invalidation) and the vendor
> specific format info
On Thu, 10 Sep 2020 03:45:21 -0700
Liu Yi L wrote:
> Shared Virtual Addressing (a.k.a Shared Virtual Memory) allows sharing
> multiple process virtual address spaces with the device for simplified
> programming model. PASID is used to tag an virtual address space in DMA
> requests and to identify
On Thu, 10 Sep 2020 03:45:24 -0700
Liu Yi L wrote:
> This patch allows userspace to request PASID allocation/free, e.g. when
> serving the request from the guest.
>
> PASIDs that are not freed by userspace are automatically freed when the
> IOASID set is destroyed when process exits.
>
> Cc: Ke
IOMMU UAPI is newly introduced to support communications between guest
virtual IOMMU and host IOMMU. There has been lots of discussions on how
it should work with VFIO UAPI and userspace in general.
This document is intended to clarify the UAPI design and usage. The
mechanics of how future extensi
IOMMU UAPI data size is filled by the user space which must be validated
by the kernel. To ensure backward compatibility, user data can only be
extended by either re-purpose padding bytes or extend the variable sized
union at the end. No size change is allowed before the union. Therefore,
the minim
User APIs such as iommu_sva_unbind_gpasid() may also be used by the
kernel. Since we introduced user pointer to the UAPI functions,
in-kernel callers cannot share the same APIs. In-kernel callers are also
trusted, there is no need to validate the data.
We plan to have two flavors of the same API f
There can be multiple vendor-specific PASID data formats used in UAPI
structures. This patch adds enum type with a last entry which makes
range checking much easier.
Suggested-by: Alex Williamson
Reviewed-by: Eric Auger
Signed-off-by: Jacob Pan
---
include/uapi/linux/iommu.h | 8 ++--
1 fi
IOMMU user APIs are responsible for processing user data. This patch
changes the interface such that user pointers can be passed into IOMMU
code directly. Separate kernel APIs without user pointers are introduced
for in-kernel users of the UAPI functionality.
IOMMU UAPI data has a user filled args
IOMMU user API header was introduced to support nested DMA translation and
related fault handling. The current UAPI data structures consist of three
areas that cover the interactions between host kernel and guest:
- fault handling
- cache invalidation
- bind guest page tables, i.e. guest PASID
IOMMU generic layer already does sanity checks on UAPI data for version
match and argsz range based on generic information.
This patch adjusts the following data checking responsibilities:
- removes the redundant version check from VT-d driver
- removes the check for vendor specific data size
- ad
As IOMMU UAPI gets extended, user data size may increase. To support
backward compatibiliy, this patch introduces a size field to each UAPI
data structures. It is *always* the responsibility for the user to fill in
the correct size. Padding fields are adjusted to ensure 8 byte alignment.
Specific
On Thu, 10 Sep 2020 03:45:27 -0700
Liu Yi L wrote:
> Nesting translation allows two-levels/stages page tables, with 1st level
> for guest translations (e.g. GVA->GPA), 2nd level for host translations
> (e.g. GPA->HPA). This patch adds interface for binding guest page tables
> to a PASID. This PAS
On Thu, 10 Sep 2020 03:45:30 -0700
Liu Yi L wrote:
> This patch exposes PCIe PASID capability to guest for assigned devices.
> Existing vfio_pci driver hides it from guest by setting the capability
> length as 0 in pci_ext_cap_length[].
This exposes the PASID capability, but it's still read-only
On 2020/9/9 15:05, Christoph Hellwig wrote:
+static inline void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
+ struct iommu_domain
*domain)
This adds a crazy long line. Which is rather pointless as other
bits of code in the patch use the mo
On 2020/9/9 15:06, Christoph Hellwig wrote:
On Wed, Sep 09, 2020 at 09:43:09AM +0800, Lu Baolu wrote:
+ /*
+* The Intel graphic device driver is used to assume that the
returned
+* sg list is not combound. This blocks the efforts of converting
the
This adds pointless over
From: Tom Murphy
Convert the intel iommu driver to the dma-iommu api. Remove the iova
handling and reserve region code from the intel iommu driver.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/Kconfig | 1 +
drivers/iommu/intel/iommu.c | 742 ++--
From: Tom Murphy
Add a iommu_dma_free_cpu_cached_iovas function to allow drivers which
use the dma-iommu ops to free cached cpu iovas.
Signed-off-by: Tom Murphy
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 9 +
include/linux/dma-iommu.h | 8
2 files changed, 17 ins
Some cleanups after converting the driver to use dma-iommu ops.
- Remove nobounce option;
- Cleanup and simplify the path in domain mapping.
Signed-off-by: Lu Baolu
---
.../admin-guide/kernel-parameters.txt | 5 --
drivers/iommu/intel/iommu.c | 90 ++-
From: Tom Murphy
Allow the dma-iommu api to use bounce buffers for untrusted devices.
This is a copy of the intel bounce buffer code.
Signed-off-by: Tom Murphy
Co-developed-by: Lu Baolu
Signed-off-by: Lu Baolu
---
drivers/iommu/dma-iommu.c | 163 +++---
1 file
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a follow-up with below changes:
1. Add a quirk for the i915 driver issue described in Tom's cover
letter.
2.
From: Tom Murphy
Allow the iommu_unmap_fast to return newly freed page table pages and
pass the freelist to queue_iova in the dma-iommu ops path.
This is useful for iommu drivers (in this case the intel iommu driver)
which need to wait for the ioTLB to be flushed before newly
free/unmapped page
Combining the sg segments exposes a bug in the Intel i915 driver which
causes visual artifacts and the screen to freeze. This is most likely
because of how the i915 handles the returned list. It probably doesn't
respect the returned value specifying the number of elements in the list
and instead de
Hi Alex,
> From: Alex Williamson
> Sent: Saturday, September 12, 2020 6:04 AM
>
> On Thu, 10 Sep 2020 03:45:27 -0700
> Liu Yi L wrote:
>
> > Nesting translation allows two-levels/stages page tables, with 1st
> > level for guest translations (e.g. GVA->GPA), 2nd level for host
> > translations
Hi Alex,
> From: Alex Williamson
> Sent: Saturday, September 12, 2020 5:38 AM
>
> On Thu, 10 Sep 2020 03:45:24 -0700
> Liu Yi L wrote:
>
> > This patch allows userspace to request PASID allocation/free, e.g. when
> > serving the request from the guest.
> >
> > PASIDs that are not freed by user
On Fri, Sep 11, 2020 at 05:12:36PM +0100, Robin Murphy wrote:
> (apologies to Jim - I did look through one of the previous versions since I
> last commented and thought it looked OK, but never actually replied as
> such)
>
> On 2020-09-10 06:40, Christoph Hellwig wrote:
>> From: Jim Quinlan
>>
>
70 matches
Mail list logo
