Currently we do not clear added dirty bit of bitmap when unwind
pin, so if pin failed at halfway, we set unnecessary dirty bit
in bitmap. Clearing added dirty bit when unwind pin, userspace
will see less dirty page, which can save much time to handle them.
Note that we should distinguish the bits
We always use the smallest supported page size of vfio_iommu as
pgsize. Remove parameter "pgsize" of vfio_iova_dirty_bitmap.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c
Currently there are 3 ways to promote the pinned_page_dirty_scope
status of vfio_iommu:
1. Through pin interface.
2. Detach a group without dirty tracking.
3. Attach a group with dirty tracking.
For point 3, the only chance to change the pinned status is that
the vfio_iommu is newly created.
When we pin or detach a group which is not dirty tracking capable,
we will try to promote pinned_scope of vfio_iommu.
If we succeed to do so, vfio only report pinned_scope as dirty to
userspace next time, but these memory written before pin or detach
is missed.
The solution is that we must
When we want to promote pinned_page_scope of vfio_iommu, we
should call the "update" function to visit all vfio_group,
but when we want to downgrade it, we can set the flag directly.
Giving above, we can give an explicit "promote" semantic to
that function. BTW, if vfio_iommu has been promoted,
We always use the smallest supported page size of vfio_iommu as
pgsize. Remove parameter "pgsize" of vfio_dma_bitmap_alloc_all.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
On Wed, Dec 9, 2020 at 6:07 PM Logan Gunthorpe wrote:
>
>
>
> On 2020-12-09 6:22 p.m., Dan Williams wrote:
> > On Mon, Nov 9, 2020 at 8:47 AM Logan Gunthorpe wrote:
> >>
> >>
> >>
> >> On 2020-11-09 2:12 a.m., Christoph Hellwig wrote:
> >>> On Fri, Nov 06, 2020 at 10:00:25AM -0700, Logan
From: Adrian Huang
From: Adrian Huang
The values of local variables are assigned after local variables
are declared, so no need to assign the initial value during the
variable declaration.
And, no need to assign NULL for the local variable 'ivrs_base'
after invoking acpi_put_table().
On 2020-12-09 6:22 p.m., Dan Williams wrote:
> On Mon, Nov 9, 2020 at 8:47 AM Logan Gunthorpe wrote:
>>
>>
>>
>> On 2020-11-09 2:12 a.m., Christoph Hellwig wrote:
>>> On Fri, Nov 06, 2020 at 10:00:25AM -0700, Logan Gunthorpe wrote:
We make use of the top bit of the dma_length to indicate
From: Ashish Kalra
For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
SEV uses SWIOTLB to make this happen without requiring changes to device
drivers. However, depending on the workload being run, the default 64MB
of it might not be enough and it may run out of buffers
On Mon, Nov 9, 2020 at 8:47 AM Logan Gunthorpe wrote:
>
>
>
> On 2020-11-09 2:12 a.m., Christoph Hellwig wrote:
> > On Fri, Nov 06, 2020 at 10:00:25AM -0700, Logan Gunthorpe wrote:
> >> We make use of the top bit of the dma_length to indicate a P2PDMA
> >> segment.
> >
> > I don't think "we" can.
> > The Tegra Next Generation SOC uses arm-smmu-v3, but it doesn't have support
> > for BTM.
> > Do you have plan to get your earlier patch to handle invalidate
> > notifications into upstream sometime soon?
>Is that a limitation of the SMMU implementation, the interconnect or the
On Wed, Dec 09, 2020 at 07:49:09PM +, Krishna Reddy wrote:
> > > Why is BTM mandated for SVA? I couldn't find this requirement in
> > > SMMU spec (Sorry if I missed it or this got discussed earlier). But
> > > if performance is the
> > only concern here,
> > > is it better just to allow it
Hi Jean,
> > Why is BTM mandated for SVA? I couldn't find this requirement in
> > SMMU spec (Sorry if I missed it or this got discussed earlier). But
> > if performance is the
> only concern here,
> > is it better just to allow it with a warning rather than limiting
> > SMMUs without
> BTM?
>
>
On Wed, Dec 09, 2020 at 07:34:16PM +, Ashish Kalra wrote:
> This should work, but i am concerned about making IO_TLB_DEFAULT_SIZE
> (which is pretty much private to generic swiotlb code) to be visible
> externally, i don't know if there are any concerns with that ?
Meh, it's just a define and
On Wed, Dec 09, 2020 at 06:51:05PM +0100, Borislav Petkov wrote:
> On Wed, Dec 09, 2020 at 01:19:46PM +, Ashish Kalra wrote:
> > reserve_crashkernel() calls swiotlb_size_or_default() to get SWIOTLB
> ...
>
> Thanks for explaining.
>
> > There is a need to introduce an architecture specific
On Wed, Dec 9, 2020 at 12:18 PM Linus Torvalds
wrote:
>
> On Wed, Dec 9, 2020 at 11:12 AM Jerry Snitselaar wrote:
> >
> > Since the field in the device table entry format expects it to be n
> > where there are 2^n entries in the table I guess it should be:
> >
> > #define DTE_IRQ_TABLE_LEN 9
> >
On Wed, Dec 9, 2020 at 11:12 AM Jerry Snitselaar wrote:
>
> Since the field in the device table entry format expects it to be n
> where there are 2^n entries in the table I guess it should be:
>
> #define DTE_IRQ_TABLE_LEN 9
> #define MAX_IRQS_PER_TABLE (1 << DTE_IRQ_TABLE_LEN)
No, that
On Wed, Dec 9, 2020 at 12:12 PM Jerry Snitselaar wrote:
>
>
> Will Deacon @ 2020-12-09 11:50 MST:
>
> > On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote:
> >> On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote:
> >> >
> >> > Please pull this one-liner AMD IOMMU fix for 5.10. It's
Will Deacon @ 2020-12-09 11:50 MST:
> On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote:
>> On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote:
>> >
>> > Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
>> > for a fix, where the size of the interrupt remapping
On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote:
> On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote:
> >
> > Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
> > for a fix, where the size of the interrupt remapping table was increased
> > but a related
A similar crash to the following could be observed if initial CPU rcache
magazine allocations fail in init_iova_rcaches():
Unable to handle kernel NULL pointer dereference at virtual address
Mem abort info:
free_iova_fast+0xfc/0x280
iommu_dma_free_iova+0x64/0x70
Add a helper function to free the CPU rcache for all online CPUs.
There also exists a function of the same name in
drivers/iommu/intel/iommu.c, but the parameters are different, and there
should be no conflict.
Signed-off-by: John Garry
Tested-by: Xiang Chen
Reviewed-by: Zhen Lei
---
The pull request you sent on Wed, 9 Dec 2020 14:12:38 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/iommu-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ca4bbdaf171604841f77648a2877e2e43db69b71
Thank you!
--
Deet-doot-dot, I am a
On Wed, Dec 09, 2020 at 01:19:46PM +, Ashish Kalra wrote:
> reserve_crashkernel() calls swiotlb_size_or_default() to get SWIOTLB
...
Thanks for explaining.
> There is a need to introduce an architecture specific callback
> for swiotlb_adjust() because of the following reason :
So what your
On Wed, Dec 09, 2020 at 03:32:50PM +, Adrian Huang12 wrote:
> Gentle ping.
Sorry, I hadn't noticed this patch.
However, I haven't been able to apply this successfully as b4 doesn't seem
to identify it as a patch and I only have this reply in my mailbox. Please
can you send it again, with me
Based on arm64 for-next/iommu/core
I'll try to bunch this sort of stuff more in future, Thanks
John Garry (3):
iova: Make has_iova_flush_queue() private
iova: Delete copy_reserved_iova()
iova: Stop exporting some more functions
drivers/iommu/iova.c | 36
Since commit c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the
iommu ops"), function copy_reserved_iova() is not referenced, so delete
it.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 30 --
include/linux/iova.h | 6 --
2 files changed, 36
Function has_iova_flush_queue() has no users outside iova.c, so make it
private.
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 2 +-
include/linux/iova.h | 6 --
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index
Gentle ping.
-- Adrian
> -Original Message-
> From: Adrian Huang
> Sent: Monday, October 12, 2020 3:01 PM
> To: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org; Adrian Huang
> ; Adrian Huang12
> Subject: [External] [PATCH 1/1] iommu/amd: Remove unnecessary assignment
>
> From:
On Tue, Dec 8, 2020 at 1:54 PM Tomasz Figa wrote:
>
> In any case, Sergey is going to share a preliminary patch on how the
> current API would be used in the V4L2 videobuf2 framework. That should
> give us more input on how such a helper could look.
>
My current WIP (deep WIP) series can be
Hi Eric,
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 18 November 2020 11:22
> To: eric.auger@gmail.com; eric.au...@redhat.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu;
[AMD Public Use]
> -Original Message-
> From: Merger, Edgar [AUTOSOL/MAS/AUGS]
> Sent: Wednesday, December 9, 2020 2:59 AM
> To: Deucher, Alexander ; Huang, Ray
> ; Kuehling, Felix
> Cc: Will Deacon ; linux-ker...@vger.kernel.org;
> linux- p...@vger.kernel.org;
Hi Linus,
Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
for a fix, where the size of the interrupt remapping table was increased
but a related constant for the size of the interrupt table was forgotten.
Cheers,
Will
--->8
The following changes since commit
On Wed, Dec 09, 2020 at 01:54:42PM +0100, Borislav Petkov wrote:
> On Wed, Dec 09, 2020 at 12:29:07PM +, Ashish Kalra wrote:
> > As i mentioned in the main comments above, this cannot be called in
> > mem_encrypt_init() as that breaks reserve_crashkernel() which depends
> > on SWIOTLB buffer
On Wed, 9 Dec 2020 12:20:19 +0100, Christoph Hellwig wrote:
> The function has a single caller, so open code it there and take
> advantage of the precalculated page count variable.
Applied to arm64 (for-next/iommu/core), thanks!
[1/1] dma-iommu: remove __iommu_dma_mmap
On 2020-12-09 11:12, Christoph Hellwig wrote:
On Tue, Dec 08, 2020 at 01:54:00PM +0900, Tomasz Figa wrote:
>From the media perspective, it would be good to have the vmap
optional, similarly to the DMA_ATTR_NO_KERNEL_MAPPING attribute for
coherent allocations. Actually, in the media drivers, the
On Wed, Dec 09, 2020 at 12:29:07PM +, Ashish Kalra wrote:
> As i mentioned in the main comments above, this cannot be called in
> mem_encrypt_init() as that breaks reserve_crashkernel() which depends
> on SWIOTLB buffer size
Please elaborate how does it break.
> and is called before
On Wed, Dec 09, 2020 at 12:01:15PM +0100, Borislav Petkov wrote:
> > Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV
> > guests.
>
> Fix subject prefix to "x86, swiotlb: ... SWIOTLB ... for SEV guests
>
> Fix typo and no fullstop at the end.
>
> On Mon, Dec 07, 2020
At line 362 in drivers/iommu/fsl_pamu_domain.c, the ret-val of
kmem_cache_zalloc should be checked to avoid null-ptr-deref bug.
Signed-off-by: tangzhenhao
---
drivers/iommu/fsl_pamu_domain.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/fsl_pamu_domain.c
On 2020-12-09 11:20, Christoph Hellwig wrote:
The function has a single caller, so open code it there and take
advantage of the precalculated page count variable.
I can't shake the feeling that we've written this patch at least twice
before through all the refactoring, so definitely no
On 2020/12/9 19:39, John Garry wrote:
> On 09/12/2020 09:03, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2020/11/17 18:25, John Garry wrote:
>>> A similar crash to the following could be observed if initial CPU rcache
>>> magazine allocations fail in init_iova_rcaches():
>>>
>>> Unable to handle
On 2020/12/9 19:22, John Garry wrote:
> On 09/12/2020 09:13, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2020/11/17 18:25, John Garry wrote:
>>> Leizhen reported some time ago that IOVA performance may degrade over time
>>> [0], but unfortunately his solution to fix this problem was not given
>>>
On Tue, Dec 08, 2020 at 01:54:00PM +0900, Tomasz Figa wrote:
> >From the media perspective, it would be good to have the vmap
> optional, similarly to the DMA_ATTR_NO_KERNEL_MAPPING attribute for
> coherent allocations. Actually, in the media drivers, the need to have
> a kernel mapping of the DMA
> Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV
> guests.
Fix subject prefix to "x86, swiotlb: ... SWIOTLB ... for SEV guests
Fix typo and no fullstop at the end.
On Mon, Dec 07, 2020 at 11:10:57PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For SEV, all
On Wed, Dec 09, 2020 at 10:01:49AM +, Song Bao Hua (Barry Song) wrote:
>
>
> > -Original Message-
> > From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> > Sent: Wednesday, December 9, 2020 8:00 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: iommu@lists.linux-foundation.org
> >
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Wednesday, December 9, 2020 8:00 PM
> To: Song Bao Hua (Barry Song)
> Cc: iommu@lists.linux-foundation.org
> Subject: [bug report] dma-mapping: add benchmark support for streaming DMA
> APIs
>
>
On 2020/11/17 18:25, John Garry wrote:
> Leizhen reported some time ago that IOVA performance may degrade over time
> [0], but unfortunately his solution to fix this problem was not given
> attention.
>
> To summarize, the issue is that as time goes by, the CPU rcache and depot
> rcache
I am the author of MediaTek iommu driver, and will to maintain and
develop it further.
Add myself to cover these items.
Signed-off-by: Yong Wu
Reviewed-by: Chun-Kuang Hu
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
Add mt8192 iommu support.
For multi domain, Add 1M gap for the vdec domain size. That is because
vdec HW has a end address register which require (start_addr +
len) rather than (start_addr + len - 1). Take a example, if the start_addr
is 0xfff0, size is 0x10, then the end_address is
Add "struct mtk_iommu_data *" in the "struct mtk_iommu_domain",
reduce the call mtk_iommu_get_m4u_data().
No functional change.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c
Some HW IP(ex: CCU) require the special iova range. That means the
iova got from dma_alloc_attrs for that devices must locate in his
special range. In this patch, we allocate a special iova_range for
each a special requirement and create each a iommu domain for each
a iova_range.
meanwhile we
If the iova is over 32bit, the fault status register bit is a little
different.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index
Defaultly the iova range is 0-4G. here we add a single-domain(0-4G)
for the previous SoC. this also is a preparing patch for supporting
multi-domains.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
If the iova is 34bit, the iova[32][33] is the bit0/1 in the tlb flush
register. Add a new macro for this.
there is a minor change unrelated with this patch. it also use the new
macro.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 11 +++
1 file changed, 7 insertions(+), 4
After extending v7s, our pagetable already support iova reach
16GB(34bit). the master got the iova via dma_alloc_attrs may reach
34bits, but its HW register still is 32bit. then how to set the
bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
we separate whole 16GB iova to four
For multiple iommu_domains, we need to reserve some iova regions. Take a
example, If the default iova region is 0 ~ 4G, but the 0x4000_ ~
0x43ff_ is only for the special CCU0 domain. Thus we should exclude
this region for the default iova region.
This patch adds iova reserved flow. It's a
This patch adds pm runtime callback.
In pm runtime case, all the registers backup/restore and bclk are
controlled in the pm_runtime callback, then pm_suspend is not needed in
this case.
runtime PM is disabled when suspend, thus we call
pm_runtime_status_suspended instead of pm_runtime_suspended.
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.
When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common,
In the lastest SoC, M4U has its special power domain. thus, If the engine
begin to work, it should help enable the power for M4U firstly.
Currently if the engine work, it always enable the power/clocks for
smi-larbs/smi-common. This patch adds device_link for smi-common and M4U.
then, if
Add fail handle for iommu_device_sysfs_add and iommu_device_register.
Fixes: b16c0170b53c ("iommu/mediatek: Make use of iommu_device_register
interface")
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git
The standard input iova bits is 32. MediaTek quad the lvl1 pagetable
(4 * lvl1). No change for lvl2 pagetable. Then the iova bits can reach
34bit.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 7 ---
1 file changed, 4 insertions(+), 3
In attach device, it will update the pagetable base address register.
Move the hw_init function also here. Then it only need call
pm_runtime_get/put one time here if m4u has power domain.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 10 ++
1 file changed, 6 insertions(+), 4
Add a HW flag for if the HW support 34bit IOVA. the previous SoC
still use 32bit. normally the lvl1 pgtable size is 16KB when ias == 32.
if ias == 34, lvl1 pgtable size is 16KB * 4. The purpose of this patch
is to save 16KB*3 continuous memory for the previous SoC.
Signed-off-by: Yong Wu
---
Add "cfg" as a parameter for some macros. This is a preparing patch for
mediatek extend the lvl1 pgtable. No functional change.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 36 +++---
1 file changed, 18
The current _ARM_V7S_LVL_BITS/ARM_V7S_LVL_SHIFT use a formula to calculate
the corresponding value for level1 and level2 to pretend the code sane.
Actually their level1 and level2 values are different from each other.
This patch only clarify the two macro. No functional change.
Suggested-by:
MediaTek extend the bit5 in lvl1 and lvl2 descriptor as PA34.
Signed-off-by: Yong Wu
Acked-by: Will Deacon
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 9 +++--
drivers/iommu/mtk_iommu.c | 2 +-
include/linux/io-pgtable.h | 4 ++--
3 files changed,
Use the ias for the valid iova checking in arm_v7s_unmap. This is a
preparing patch for supporting iova 34bit for MediaTek.
Signed-off-by: Yong Wu
Reviewed-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Use the common larb-port header in the source code.
Signed-off-by: Yong Wu
Acked-by: Krzysztof Kozlowski
---
drivers/iommu/mtk_iommu.c | 7 ---
drivers/iommu/mtk_iommu.h | 1 +
drivers/memory/mtk-smi.c | 1 +
include/soc/mediatek/smi.h | 2 --
4 files changed, 2 insertions(+), 9
This patch adds decriptions for mt8192 IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
|
Only rename the header guard for all the SoC larb port header file.
No funtional change.
Suggested-by: Krzysztof Kozlowski
Signed-off-by: Yong Wu
---
include/dt-bindings/memory/mt2701-larb-port.h | 4 ++--
include/dt-bindings/memory/mt2712-larb-port.h | 4 ++--
In the latest SoC, there are several HW IP require a sepecial iova
range, mainly CCU and VPU has this requirement. Take CCU as a example,
CCU require its iova locate in the range(0x4000_ ~ 0x43ff_).
In this patch we add a domain definition for the special port. In the
example of CCU, If
Convert MediaTek IOMMU to DT schema.
Signed-off-by: Yong Wu
Reviewed-by: Rob Herring
---
.../bindings/iommu/mediatek,iommu.txt | 105 ---
.../bindings/iommu/mediatek,iommu.yaml| 167 ++
2 files changed, 167 insertions(+), 105 deletions(-)
delete mode
Extend the max larb number definition as mt8192 has larb_nr over 16.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 2 +-
include/dt-bindings/memory/mtk-smi-larb-port.h | 4 ++--
2 files
Put all the macros about smi larb/port togethers, this is a preparing
patch for extending LARB_NR and adding new dom-id support.
Signed-off-by: Yong Wu
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
---
include/dt-bindings/memory/mt2712-larb-port.h | 2 +-
This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
table format. The M4U-SMI HW diagram is as below:
EMI
|
M4U
76 matches
Mail list logo
