The MMU_CTRL register of MT8173 is different from other SoCs.
The in_order_wr_en is bit[9] which is zero by default.
Other SoCs have the vitcim_tlb_en feature mapped to bit[12].
This bit is set to one by default. We need to preserve the bit
when setting F_MMU_TF_PROT_TO_PROGRAM_ADDR as otherwise
This patch adds description for MT6779 IOMMU.
MT6779 has two iommus, they are mm_iommu and apu_iommu which
both use ARM Short-Descriptor translation format.
In addition, mm_iommu and apu_iommu are two independent HW instance
, we need to set them separately.
The MT6779 IOMMU hardware diagram is
1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
2. Add mt6779_data to support mm_iommu HW init.
Cc: Yong Wu
Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 9 +
Starting with mt6779, iommu needs to extend to 256 bytes from 128
bytes which can send the max number of data for memory protection
pa alignment. So we can use a separate patch to modify it.
Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file
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_MMU_MISC_CTRL may be more proper.
This patch only rename
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 a flag present.
No functional change.
Cc: Yong Wu
Suggested-by: Matthias Brugger
Signed-off-by: Chao Hao
This patchset adds mt6779 iommu support.
mt6779 has two iommus, they are MM_IOMMU(M4U) and APU_IOMMU which used ARM
Short-Descriptor translation format.
The mt6779's MM_IOMMU-SMI and APU_IOMMU HW diagram is as below, it is only a
brief diagram:
EMI
For mt6779, MMU_INV_SEL register's offset is changed from
0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
use it.
In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
before mt6779.
Cc: Yong Wu
Signed-off-by: Chao Hao
Reviewed-by: Matthias Brugger
---
Add F_MMU_IN_ORDER_WR_EN_MASK and F_MMU_STANDARD_AXI_MODE_EN_MASK
definitions in MISC_CTRL register.
F_MMU_STANDARD_AXI_MODE_EN_MASK:
If we set F_MMU_STANDARD_AXI_MODE_EN_MASK (bit[3][19] = 0, not follow
standard AXI protocol), the iommu will priorize sending of urgent read
command over a normal
Some platforms(ex: mt6779) need to improve performance by setting
REG_MMU_WR_LEN_CTRL register. And we can use WR_THROT_EN macro to control
whether we need to set the register. If the register uses default value,
iommu will send command to EMI without restriction, when the number of
commands
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-id;
bit[8:7] means subcommon-id;
>From these two variables,
> From: Alex Williamson
> Sent: Friday, July 3, 2020 1:55 AM
>
> On Wed, 24 Jun 2020 01:55:15 -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.
> >
> > This patch
> From: Williamson < alex.william...@redhat.com >
> Sent: Friday, July 3, 2020 5:20 AM
>
> On Wed, 24 Jun 2020 01:55:23 -0700
> Liu Yi L wrote:
>
> > This patch provides an interface allowing the userspace to invalidate
> > IOMMU cache for first-level page table. It is required when the first
>
> From: Alex Williamson
> Sent: Friday, July 3, 2020 5:21 AM
> To: Liu, Yi L
>
> On Wed, 24 Jun 2020 01:55:14 -0700
> Liu Yi L wrote:
>
> > 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
> >
On Wed, 2020-07-01 at 16:58 +0200, Matthias Brugger wrote:
>
> On 30/06/2020 12:53, chao hao wrote:
> > 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
On Wed, 2020-07-01 at 10:17 +0800, Yong Wu wrote:
> 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:
On Wed, 24 Jun 2020 01:55:14 -0700
Liu Yi L wrote:
> 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
On Wed, 24 Jun 2020 01:55:23 -0700
Liu Yi L wrote:
> 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.
>
>
On Wed, 24 Jun 2020 01:55:22 -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
On Wed, 24 Jun 2020 01:55:19 -0700
Liu Yi L wrote:
> 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:
On Wed, 24 Jun 2020 01:55:17 -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
We already have 'cfg_probe' hook which meant to override and apply
workarounds while probing ID registers. However, 'cfg_probe' is called
at the very end and therefore for some cases fixing up things becomes complex
or requires exporting of SMMU driver structures. Hence, seems it is better and
From: Marcin Wojtas
Add IOMMU node for Marvell AP806 based SoCs together with platform
and PCI device Stream ID mapping.
Signed-off-by: Marcin Wojtas
Signed-off-by: Tomasz Nowicki
---
arch/arm64/boot/dts/marvell/armada-8040.dtsi | 36 +++
There were already two versions of series to support SMMU for AP806,
including workaround for accessing ARM SMMU 64bit registers.
First [1] by Hanna Hawa and second [2] by Gregory CLEMENT.
Since it got stuck this is yet another try. I incorporated the V2 comments,
mainly by moving workaround code
Add specific compatible string for Marvell usage due to errata of
accessing 64bits registers of ARM SMMU, in AP806.
AP806 SoC uses the generic ARM-MMU500, and there's no specific
implementation of Marvell, this compatible is used for errata only.
Signed-off-by: Hanna Hawa
Signed-off-by: Gregory
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit to
ARM SMMUv2 registers.
Provide implementation relevant hooks:
- split the writeq/readq to two accesses of writel/readl.
- mask the MMU_IDR2.PTFSv8 fields to not use AArch64 format (but
only AARCH32_L) since
On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse wrote:
>
> 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
Hi, Felix, Thomas, Joerg and maintainers,
On Tue, Jun 30, 2020 at 10:12:38PM -0400, Felix Kuehling wrote:
> Am 2020-06-30 um 7:44 p.m. schrieb Fenghua Yu:
> You didn't change the return types of amdgpu_pasid_alloc and
> kfd_pasid_alloc. amdgpu_pasid_alloc returns int, because it can return
>
On Wed, 24 Jun 2020 01:55:16 -0700
Liu Yi L wrote:
> 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
On Wed, 24 Jun 2020 01:55:15 -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.
>
> This patch reports nesting info by DOMAIN_ATTR_NESTING. Caller can get
> nesting info after
[AMD Public Use]
> -Original Message-
> From: Kai-Heng Feng
> Sent: Thursday, July 2, 2020 8:04 AM
> To: Joerg Roedel
> Cc: Deucher, Alexander ;
> iommu@lists.linux-foundation.org; open list
> Subject: [BUG] "Pre-boot DMA Protection" makes AMDGPU stop working
>
> Hi,
>
> A more
On 2020-07-01 20:39, Krishna Reddy wrote:
On 01/07/2020 20:00, Krishna Reddy wrote:
+items:
+ - enum:
+ - nvdia,tegra194-smmu
+ - const: arm,mmu-500
Is the fallback compatible appropriate here? If software treats this as a
standard MMU-500 it will only
On Thu, Jun 25, 2020 at 12:10:39AM +, John Stultz wrote:
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index b510f67dfa49..714893535dd2 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -381,6 +381,7 @@ config SPAPR_TCE_IOMMU
> config ARM_SMMU
>
Hi Jean,
Just realized I should send this to your Linaro account instead of ARM.
So Hi again :)
On Wed, 1 Jul 2020 23:29:16 -0700
Jacob Pan wrote:
> Hi Jean,
>
> Have a question for you on whether we can have a fixed token type for
> ioasid_set.
>
> Currently, ioasid_set has an arbitrary
Hi Eric,
On Thu, 2 Jul 2020 10:47:39 +0200
Auger Eric wrote:
> Hi,
>
> On 7/1/20 5:33 PM, 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
On Thu, Jun 25, 2020 at 12:10:39AM +, John Stultz wrote:
> Allow the qcom_scm driver to be loadable as a
> permenent module.
>
> Cc: Andy Gross
> Cc: Bjorn Andersson
> Cc: Joerg Roedel
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Linus Walleij
> Cc: Maulik Shah
>
Hi,
A more detailed bug report can be found at [1].
I have a AMD Renoir system that can't enter graphical session because there are
many IOMMU splat.
Alex suggested to disable "Pre-boot DMA Protection", I can confirm once it's
disabled, AMDGPU starts working with IOMMU enabled.
So raise the
Add mediatek,infracfg to iommu node.
Signed-off-by: Miles Chen
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 70b1ffcab7f0..a6f14f68ef7e 100644
---
In previous disscusion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.
Check 4GB mode by reading infracfg register, remove the usage
of the unexported symbol max_pfn.
[1] https://lkml.org/lkml/2020/6/3/733
[2]
Add mediatek,infracfg to iommu node.
Signed-off-by: Miles Chen
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index db17d0a4ed57..0749b0f4834c 100644
---
Add a description for mediatek,infracfg. We can check if 4GB mode
is enable by reading it instead of checking the unexported
symbol "max_pfn".
This is a step towards building mtk_iommu as a kernel module.
Cc: Yong Wu
Signed-off-by: Miles Chen
---
On Thu, Jul 02, 2020 at 10:52:12AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 02, 2020 at 06:40:09PM +1000, Oliver O'Halloran wrote:
> > On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
> > > > Yep, that's a
On Thu, Jul 02, 2020 at 06:40:09PM +1000, Oliver O'Halloran wrote:
> On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
> > > Yep, that's a problem. If we want to provide a useful mechanism to
> > > userspace then the
Hi Jacob,
On 7/1/20 5:33 PM, 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
Hi,
On 7/1/20 5:33 PM, 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.
On Wed, Jul 01, 2020 at 05:21:38PM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable
On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
> > Yep, that's a problem. If we want to provide a useful mechanism to
> > userspace then the default behaviour of the kernel can't undermine
> > that mechanism. If
Hi Jacob, Yi,
On 7/1/20 5:33 PM, 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
Hi Robin,
On 2020/7/2 0:12, Robin Murphy wrote:
On 2020-06-30 14:04, Hanjun Guo wrote:
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
Hi Jacob,
On 7/1/20 5:33 PM, 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
On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
> On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote:
> >
> > *snip*
> >
> > > > I guess it would make sense to have an attribute for user space to
> > > > write to in order to make the kernel reject device plug-in events
> > > >
Hi,
On 7/1/20 5:33 PM, Jacob Pan wrote:
> 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
Hi Jacob,
On 7/1/20 5:33 PM, 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.
>
> Link: https://lkml.org/lkml/2019/8/26/651
>
Hi Jacob,
On 7/1/20 5:33 PM, 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
Hi Jean,
Have a question for you on whether we can have a fixed token type for
ioasid_set.
Currently, ioasid_set has an arbitrary token. For VT-d vSVA usage, we
choose mm as ioasid_set token to identify PASIDs within a guest. We have
multiple in-kernel users of PASIDs such as VFIO, KVM, and
55 matches
Mail list logo
