Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20200611]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next v5.7]
[if your
Hi Jordan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on next-20200611]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next v5.7
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.7 next-20200611]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next]
[if your
Now the __iommu_map() and __iommu_map_sg() are used only in iommu.c
file, so mark them as static.
Signed-off-by: Baolin Wang
---
drivers/iommu/iommu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index
Hi,
The first patch masks some functions as static, and the second patch
changes to use the gfp parameter from iommu_ops->map() to allocate
ARM page pages. Any comments are welcome. Thanks.
Changes from v1:
- Fix the building errors when enabling CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST
Baolin
Now the ARM page tables are always allocated by GFP_ATOMIC parameter,
but the iommu_ops->map() function has been added a gfp_t parameter by
commit 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map"),
thus io_pgtable_ops->map() should use the gfp parameter passed from
iommu_ops->map() to
On Thu, Jun 11, 2020 at 3:29 PM Jordan Crouse wrote:
>
> Add support for using per-instance pagetables if all the dependencies are
> available.
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 69 ++-
>
On Thu, 11 Jun 2020 14:40:47 -0600
Alex Williamson wrote:
> On Thu, 11 Jun 2020 12:52:05 -0700
> Jacob Pan wrote:
>
> > Hi Alex,
> >
> > On Thu, 11 Jun 2020 09:47:41 -0600
> > Alex Williamson wrote:
> >
> > > On Wed, 10 Jun 2020 21:12:13 -0700
> > > Jacob Pan wrote:
> > >
> > > >
On Thu, 11 Jun 2020 10:49:36 -0600
Alex Williamson wrote:
> On Wed, 10 Jun 2020 21:12:14 -0700
> Jacob Pan wrote:
>
> > 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
On Thu, 11 Jun 2020 14:55:18 -0600
Alex Williamson wrote:
> On Thu, 11 Jun 2020 13:02:24 -0700
> Jacob Pan wrote:
>
> > On Thu, 11 Jun 2020 11:08:16 -0600
> > Alex Williamson wrote:
> >
> > > On Wed, 10 Jun 2020 21:12:15 -0700
> > > Jacob Pan wrote:
> > >
> > > > IOMMU UAPI data has
Add a new implementation hook to allow the implementation specific code
to tweek the context bank configuration just before it gets written.
The first user will be the Adreno GPU implementation to turn on
SCTLR.HUPCF to ensure that a page fault doesn't terminating pending
transactions. Doing so
The Adreno GPU has the capacity to manage its own pagetables and switch
them dynamically from the hardware. Add a domain attribute for arm-smmu-v2
to get the default pagetable configuration so that the GPU driver can match
the format for its own pagetables.
Signed-off-by: Jordan Crouse
---
Add support for using per-instance pagetables if all the dependencies are
available.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 69 ++-
drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
2 files changed, 69 insertions(+), 1 deletion(-)
diff
Support auxiliary domains for arm-smmu-v2 to initialize and support
multiple pagetables for a single SMMU context bank. Since the smmu-v2
hardware doesn't have any built in support for switching the pagetable
base it is left as an exercise to the caller to actually use the pagetable.
Aux domains
Add support to create a io-pgtable for use by targets that support
per-instance pagetables. In order to support per-instance pagetables the
GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
split pagetables and auxiliary domains need to be supported and enabled.
Add support for allocating an address space instance. Targets that support
per-instance pagetables should implement their own function to allocate a
new instance. The default will return the existing generic address space.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 15
This is a new refresh of support for auxiliary domains for arm-smmu-v2
and per-instance pagetables for drm/msm. The big change here from past
efforts is that outside of creating a single aux-domain to enable TTBR0
all of the per-instance pagetables are created and managed exclusively
in drm/msm
Allow a io-pgtable implementation to skip TLB operations by checking for
NULL pointers in the helper functions. It will be up to to the owner
of the io-pgtable instance to make sure that they independently handle
the TLB correctly.
Signed-off-by: Jordan Crouse
---
include/linux/io-pgtable.h |
Add a special implementation for the SMMU attached to most Adreno GPU
target triggered from the qcom,adreno-gpu-smmu compatible string. When
selected the driver will attempt to enable split pagetables.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm-smmu-impl.c | 3 +++
Every Qcom Adreno GPU has an embedded SMMU for its own use. These
devices depend on unique features such as split pagetables,
different stall/halt requirements and other settings. Identify them
with a compatible string so that they can be identified in the
arm-smmu implementation specific code.
Enable TTBR1 for a context bank if IO_PGTABLE_QUIRK_ARM_TTBR1 is selected
by the io-pgtable configuration.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm-smmu.c | 21 -
drivers/iommu/arm-smmu.h | 25 +++--
2 files changed, 35 insertions(+), 11
Construct the io-pgtable config before calling the implementation specific
init_context function and pass it so the implementation specific function
can get a chance to change it before the io-pgtable is created.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm-smmu-impl.c | 3 ++-
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
Add a link to the pointer to the struct device that is attached to a
domain. This makes it easy to get the pointer if it is needed in the
implementation specific code.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm-smmu.c | 1 +
drivers/iommu/arm-smmu.h | 1 +
2 files changed, 2
Another iteration of the split-pagetable support for arm-smmu and the Adreno GPU
SMMU. After email discussions [1] we opted to make a arm-smmu implementation for
specifically for the Adreno GPU and use that to enable split pagetable support
and later other implementation specific bits that we
Use the aperture settings from the IOMMU domain to set up the virtual
address range for the GPU. This allows us to transparently deal with
IOMMU side features (like split pagetables).
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
On Thu, 11 Jun 2020 13:02:24 -0700
Jacob Pan wrote:
> On Thu, 11 Jun 2020 11:08:16 -0600
> Alex Williamson wrote:
>
> > On Wed, 10 Jun 2020 21:12:15 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI data has an argsz field which is filled by user. As the
> > > data structures expands, argsz
On Thu, 11 Jun 2020 12:52:05 -0700
Jacob Pan wrote:
> Hi Alex,
>
> On Thu, 11 Jun 2020 09:47:41 -0600
> Alex Williamson wrote:
>
> > On Wed, 10 Jun 2020 21:12:13 -0700
> > Jacob Pan wrote:
> >
> > > IOMMU UAPI is newly introduced to support communications between
> > > guest virtual IOMMU
On Thu, 11 Jun 2020 11:08:16 -0600
Alex Williamson wrote:
> On Wed, 10 Jun 2020 21:12:15 -0700
> Jacob Pan wrote:
>
> > IOMMU UAPI data has an argsz field which is filled by user. As the
> > data structures expands, argsz may change. As the UAPI data are
> > shared among different
Hi Alex,
On Thu, 11 Jun 2020 09:47:41 -0600
Alex Williamson wrote:
> On Wed, 10 Jun 2020 21:12:13 -0700
> Jacob Pan wrote:
>
> > 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
On Thu, 11 Jun 2020 05:15:21 -0700
Liu Yi L wrote:
> IOMMUs that support nesting translation needs report the capability info
> to userspace, e.g. the format of first level/stage paging structures.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe
dma_alloc_contiguous() does size >> PAGE_SHIFT and set_memory_decrypted()
works at page granularity. It's necessary to page align the allocation
size in dma_direct_alloc_pages() for consistent behavior.
This also fixes an issue when arch_dma_prep_coherent() is called on an
unaligned allocation
When a coherent mapping is created in dma_direct_alloc_pages(), it needs
to be decrypted if the device requires unencrypted DMA before returning.
Fixes: 3acac065508f ("dma-mapping: merge the generic remapping helpers
into dma-direct")
Cc: sta...@vger.kernel.org # 5.5+
Signed-off-by: David
If arch_dma_set_uncached() fails after memory has been decrypted, it needs
to be re-encrypted before freeing.
Fixes: fa7e2247c572 ("dma-direct: make uncached_kernel_address more
general")
Cc: sta...@vger.kernel.org # 5.7
Signed-off-by: David Rientjes
---
kernel/dma/direct.c | 6 +-
1 file
While debugging recently reported issues concerning DMA allocation
practices when CONFIG_AMD_MEM_ENCRYPT is enabled, some curiosities arose
when looking at dma_direct_alloc_pages() behavior.
Fix these up. These are likely all stable material, so proposing for 5.8.
---
kernel/dma/direct.c | 42
__change_page_attr() can fail which will cause set_memory_encrypted() and
set_memory_decrypted() to return non-zero.
If the device requires unencrypted DMA memory and decryption fails, simply
free the memory and fail.
If attempting to re-encrypt in the failure path and that encryption fails,
On Wed, 10 Jun 2020 21:12:15 -0700
Jacob Pan wrote:
> IOMMU UAPI data has an argsz field which is filled by user. As the data
> structures expands, argsz may change. As the UAPI data are shared among
> different architectures, extensions of UAPI data could be a result of
> one architecture which
On Wed, 10 Jun 2020 21:12:14 -0700
Jacob Pan wrote:
> 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.
Hi Jon,
On Thu, 11 Jun 2020 07:55:00 -0600
Jonathan Corbet wrote:
> On Wed, 10 Jun 2020 21:12:13 -0700
> Jacob Pan wrote:
>
> A little nit but...this pattern:
>
> > +pattern below:
> > +
> > +::
> > +
> > + struct {
> > + __u32 argsz;
> > + __u32 flags;
> > + __u8 data[];
> > + }
On Wed, 10 Jun 2020 21:12:13 -0700
Jacob Pan wrote:
> 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 indended to
On Wed, 10 Jun 2020 21:12:13 -0700
Jacob Pan wrote:
A little nit but...this pattern:
> +pattern below:
> +
> +::
> +
> + struct {
> + __u32 argsz;
> + __u32 flags;
> + __u8 data[];
> + }
can be more concisely and attractively written as:
pattern below::
struct {
On Thu, Jun 11, 2020 at 10:54:45AM +0800, Zhangfei Gao wrote:
> On 2020/6/10 上午12:49, Bjorn Helgaas wrote:
> > On Tue, Jun 09, 2020 at 11:15:06AM +0200, Arnd Bergmann wrote:
> > > On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao
> > > wrote:
> > > > On 2020/6/9 上午12:41, Bjorn Helgaas wrote:
> > > > >
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 81 +++--
include/linux/intel-iommu.h | 16
When an IOMMU domain with nesting attribute is used for guest SVA, a
system-wide PASID is allocated for binding with the device and the domain.
For security reason, we need to check the PASID passsed from user-space.
e.g. page table bind/unbind and PASID related cache invalidation.
Cc: Kevin Tian
This patch exports iommu nesting capability info to user space through
VFIO. User space 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 information for first level/stage page table that will be
bound
This patch allows user space 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: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc:
This patch provides an interface allowing the userspace to invalidate
IOMMU cache for first-level page table. It is required when the first
level IOMMU page table is not managed by the host kernel in the nested
translation setup.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
>From IOMMU p.o.v., PASIDs allocated and managed by external components
(e.g. VFIO) will be passed in for gpasid_bind/unbind operation. IOMMU
needs some knowledge to check the PASID ownership, hence add an interface
for those components to tell the PASID owner.
In latest kernel design, PASID
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 the related translation structure in IOMMU. When
a
IOMMUs that support nesting translation needs report the capability info
to userspace, e.g. the format of first level/stage paging structures.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Liu Yi L
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[].
And this patch only exposes PASID capability for devices which has PCIe
PASID extended struture in its configuration
From: Eric Auger
The VFIO API was enhanced to support nested stage control: a bunch of
new iotcls and usage guideline.
Let's document the process to follow to set up nested mode.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Existing iommu_gpasid_bind_data is used for binding guest page tables
to a specified PASID. While for unwind it, a unbind_data structure is
needed.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Liu Yi
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 PASID must have been allocated to user space before the
binding
Recent years, mediated device pass-through framework (e.g. vfio-mdev)
is used to achieve flexible device sharing across domains (e.g. VMs).
Also there are hardware assisted mediated pass-through solutions from
platform vendors. e.g. Intel VT-d scalable mode which supports Intel
Scalable I/O
From: Yi Sun
Current interface is good enough for SVA virtualization on an assigned
physical PCI device, but when it comes to mediated devices, a physical
device may attached with multiple aux-domains. So this interface needs
to pass in domain info. Then the iommu driver is able to know which
This patch refactors the vfio_iommu_type1_ioctl() to use switch instead of
if-else, and each cmd got a helper function.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Suggested-by: Christoph Hellwig
Signed-off-by:
Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
Intel platforms allows address space sharing between device DMA and
applications. SVA can reduce programming complexity and enhance security.
This VFIO series is intended to expose SVA usage to VMs. i.e. Sharing
guest
This patch series is based on next-20200611.
Yoshihiro Shimoda (2):
dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a77961 support
iommu/renesas: Add support for r8a77961
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
drivers/iommu/ipmmu-vmsa.c
Add support for r8a77961 (R-Car M3-W+).
Signed-off-by: Yoshihiro Shimoda
---
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
Add support for r8a77961 (R-Car M3-W+).
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 4c2972f..b57b1f2 100644
--- a/drivers/iommu/ipmmu-vmsa.c
On Wed, 10 Jun 2020 21:12:13 -0700
Jacob Pan wrote:
> 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 indended to
Hi Jacob,
On 2020/6/11 12:12, Jacob Pan wrote:
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 indended to clarify the UAPI
63 matches
Mail list logo
