On Wed, Jul 14, 2021 at 10:51:34PM +0200, Arnd Bergmann wrote:
> The question is how we can best allow one but not the other.
By only allowing to allocate domains of type IDENTITY and DMA, but fail
to allocate UNMANAGED domains.
Regards,
Joerg
> From: Shenming Lu
> Sent: Thursday, July 15, 2021 2:29 PM
>
> On 2021/7/15 11:55, Tian, Kevin wrote:
> >> From: Shenming Lu
> >> Sent: Thursday, July 15, 2021 11:21 AM
> >>
> >> On 2021/7/9 15:48, Tian, Kevin wrote:
> >>> 4.6. I/O page fault
> >>> +++
> >>>
> >>> uAPI is TBD. H
On 2021/7/15 11:55, Tian, Kevin wrote:
>> From: Shenming Lu
>> Sent: Thursday, July 15, 2021 11:21 AM
>>
>> On 2021/7/9 15:48, Tian, Kevin wrote:
>>> 4.6. I/O page fault
>>> +++
>>>
>>> uAPI is TBD. Here is just about the high-level flow from host IOMMU driver
>>> to guest IOMMU dr
在 2021/7/13 下午4:46, Xie Yongji 写道:
VDUSE (vDPA Device in Userspace) is a framework to support
implementing software-emulated vDPA devices in userspace. This
document is intended to clarify the VDUSE design and usage.
Signed-off-by: Xie Yongji
---
Documentation/userspace-api/index.rst | 1 +
在 2021/7/15 下午12:03, Yongji Xie 写道:
Which ioctl can be used for this?
I mean we can introduce a new ioctl for that in the future.
Ok, I see.
I wonder if it's better to do something similar to ccw:
1) requires the userspace to update the status bit in the response
2) update the dev->st
On 6/18/2021 2:00 AM, Ashish Mhetre wrote:
Multiple iommu domains and iommu groups are getting created for the devices
sharing same SID. It is expected for devices sharing same SID to be in same
iommu group and same iommu domain.
This is leading to context faults when one device is accessing I
On Wed, Jul 14, 2021 at 5:12 PM Jason Wang wrote:
>
>
> 在 2021/7/14 下午2:49, Yongji Xie 写道:
> > On Wed, Jul 14, 2021 at 1:45 PM Jason Wang wrote:
> >>
> >> 在 2021/7/13 下午4:46, Xie Yongji 写道:
> >>> This VDUSE driver enables implementing software-emulated vDPA
> >>> devices in userspace. The vDPA de
> From: Shenming Lu
> Sent: Thursday, July 15, 2021 11:21 AM
>
> On 2021/7/9 15:48, Tian, Kevin wrote:
> > 4.6. I/O page fault
> > +++
> >
> > uAPI is TBD. Here is just about the high-level flow from host IOMMU driver
> > to guest IOMMU driver and backwards. This flow assumes that
On 2021/7/9 15:48, Tian, Kevin wrote:
> 4.6. I/O page fault
> +++
>
> uAPI is TBD. Here is just about the high-level flow from host IOMMU driver
> to guest IOMMU driver and backwards. This flow assumes that I/O page faults
> are reported via IOMMU interrupts. Some devices report fa
在 2021/7/14 下午5:57, Dan Carpenter 写道:
On Wed, Jul 14, 2021 at 05:41:54PM +0800, Jason Wang wrote:
在 2021/7/14 下午4:05, Dan Carpenter 写道:
On Wed, Jul 14, 2021 at 10:14:32AM +0800, Jason Wang wrote:
在 2021/7/13 下午7:31, Dan Carpenter 写道:
On Tue, Jul 13, 2021 at 04:46:52PM +0800, Xie Yongji wrote
在 2021/7/15 9:23, Lu Baolu 写道:
On 7/14/21 10:24 PM, Georgi Djakov wrote:
On 16.06.21 16:38, Georgi Djakov wrote:
When unmapping a buffer from an IOMMU domain, the IOMMU framework
unmaps
the buffer at a granule of the largest page size that is supported by
the IOMMU hardware and fits within t
On 7/15/21 1:28 AM, Robin Murphy wrote:
If people are going to insist on calling iommu_iova_to_phys()
pointlessly and expecting it to work, we can at least do ourselves a
favour by handling those cases in the core code, rather than repeatedly
across an inconsistent handful of drivers.
Signed-off
On 7/14/21 10:24 PM, Georgi Djakov wrote:
On 16.06.21 16:38, Georgi Djakov wrote:
When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
the buffer at a granule of the largest page size that is supported by
the IOMMU hardware and fits within the buffer. For every block that
is
On Wed, Jun 30, 2021 at 10:34:42AM +0800, Yong Wu wrote:
> In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
> mainly are PCIe and USB. Different with MM IOMMU, all these masters
> connect with IOMMU directly, there is no mediatek,larbs property for
> infra IOMMU.
>
> Another thi
On Wed, 30 Jun 2021 10:34:41 +0800, Yong Wu wrote:
> This patch adds descriptions for mt8195 IOMMU which also use ARM
> Short-Descriptor translation table format.
>
> In mt8195, there are two smi-common HW and IOMMU, one is for vdo(video
> output), the other is for vpp(video processing pipe). They
To help review changes related to AMD IOMMU.
Signed-off-by: Suravee Suthikulpanit
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b80e6f7..8022dbd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -933,6 +933,7 @@ F: drivers/video/fbdev/geode/
On Wed, Jul 14, 2021 at 8:21 PM Robin Murphy wrote:
>
> On 2021-06-27 15:34, Sven Peter wrote:
> [...]
> > In the long term, I'd like to extend the dma-iommu framework itself to
> > support iommu pagesizes with a larger granule than the CPU pagesize if that
> > is
> > something you agree with.
>
On 2021-06-27 15:34, Sven Peter wrote:
[...]
In the long term, I'd like to extend the dma-iommu framework itself to
support iommu pagesizes with a larger granule than the CPU pagesize if that is
something you agree with.
BTW this isn't something we can fully support in general. IOMMU API
users
Hi,
On Tue, Jul 13, 2021, at 21:17, Robin Murphy wrote:
> On 2021-06-27 15:34, Sven Peter wrote:
> > Apple's DART iommu uses a pagetable format that shares some
> > similarities with the ones already implemented by io-pgtable.c.
> > Add a new format variant to support the required differences
> >
If people are going to insist on calling iommu_iova_to_phys()
pointlessly and expecting it to work, we can at least do ourselves a
favour by handling those cases in the core code, rather than repeatedly
across an inconsistent handful of drivers.
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/
Hi,
On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy wrote:
>
> On 2021-07-08 15:36, Doug Anderson wrote:
> [...]
> >> Or document for the users that want performance how to
> >> change the setting, so that they can decide.
> >
> > Pushing this to the users can make sense for a Linux distribution bu
On 16.06.21 16:38, Georgi Djakov wrote:
When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
the buffer at a granule of the largest page size that is supported by
the IOMMU hardware and fits within the buffer. For every block that
is unmapped, the IOMMU framework will call int
On Tue, 2021-07-13 at 16:46 +0800, Xie Yongji wrote:
> Use tabs to indent the code instead of spaces.
There are a lot more of these in this file.
$ ./scripts/checkpatch.pl --fix-inplace --strict include/linux/vdpa.h
and a little typing gives:
---
include/linux/vdpa.h | 50 ++
From: Ville Syrjälä
I ran into some kind of fail with VT-d superpage on Geminlake igfx,
so without any better ideas let's just disable it.
Additionally Skylake/Broxton igfx have known issues with VT-d
superpage as well, so let's disable it there as well. This should
let us re-enable frame buffer
From: Ville Syrjälä
Skylake has known issues with VT-d superpage. Namely frame buffer
compression (FBC) can't be safely used when superpage is enabled.
Currently we're disabling FBC entirely when VT-d is active, but
I think just disabling superpage would be better since FBC can
save some power.
From: Ville Syrjälä
With the iommu driver disabling VT-d superpage it should be
safe to use FBC on SKL/BXT with VT-d otherwise enabled.
Cc: David Woodhouse
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 16 ---
From: Ville Syrjälä
While running "gem_exec_big --r single" from igt-gpu-tools on
Geminilake as soon as a 2M mapping is made I tend to get a DMAR
write fault. Strangely the faulting address is always a 4K page
and usually very far away from the 2M page that got mapped.
But if no 2M mappings get u
From: Ville Syrjälä
Broxton has known issues with VT-d superpage. Namely frame buffer
compression (FBC) can't be safely used when superpage is enabled.
Currently we're disabling FBC entirely when VT-d is active, but
I think just disabling superpage would be better since FBC can
save some power.
On 13/07/2021 13:34:53-0600, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems from new schema in
> the recent merge window.
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that i
On Tue, Jul 13, 2021 at 01:34:53PM -0600, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems from new schema in
> the recent merge window.
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped
> Gesendet: Mittwoch, 14. Juli 2021 um 13:18 Uhr
> Von: "Yong Wu"
> Hi Frank,
>
> Thanks for your report. mt7623 use mtk_iommu_v1.c.
>
> I will try to reproduce this locally.
Hi,
as far as i have debugged it dev->iommu_group is NULL, so it crashes on first
access (dev_info)
drivers/iommu/iommu
On Wed, 2021-07-14 at 10:59 +0200, Frank Wunderlich wrote:
> Hi,
>
> sorry this (or the 2 depency-series) cause a NULL Pointer deref in
> iommu_group_remove_device on mt7623/bpi-r2
Hi Frank,
Thanks for your report. mt7623 use mtk_iommu_v1.c.
I will try to reproduce this locally.
>
> i wonder
On Wed, 2021-07-14 at 10:56 +0200, Dafna Hirschfeld wrote:
> Hi
>
> Thanks for the patchset.
>
> I tested it on mt8173 (elm) with chromeos userspace.
> Before that patchset, the test:
>
> tast -verbose run -build=false 10.42.0.175 video.DecodeAccel.h264
>
> sometimes passed and sometimes failed
14.07.2021 13:52, Joerg Roedel пишет:
> On Mon, Jul 12, 2021 at 03:13:41AM +0300, Dmitry Osipenko wrote:
>> -err = iommu_device_sysfs_add(&smmu->iommu, dev, NULL, dev_name(dev));
>> +err = iommu_device_sysfs_add(&smmu->iommu, dev, NULL, "smmu");
>
> Are you sure no one is relying on the ol
On Wed, 2021-07-14 at 10:44 +0200, Dafna Hirschfeld wrote:
>
> On 14.07.21 04:56, Yong Wu wrote:
> > From: Yongqiang Niu
> >
> > Prepare for smi cleaning up "mediatek,larb".
> >
> > Display use the dispsys device to call pm_rumtime_get_sync before.
> > This patch add pm_runtime_xx with ovl and
On Wed, 2021-07-14 at 10:26 +0200, Dafna Hirschfeld wrote:
>
> On 14.07.21 04:56, Yong Wu wrote:
> > MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
> > smi-larb, then connect with smi-common.
> >
> > M4U
> > |
> > smi-common
> > |
> >
On Mon, Jul 12, 2021 at 03:13:41AM +0300, Dmitry Osipenko wrote:
> - err = iommu_device_sysfs_add(&smmu->iommu, dev, NULL, dev_name(dev));
> + err = iommu_device_sysfs_add(&smmu->iommu, dev, NULL, "smmu");
Are you sure no one is relying on the old name so that this change
breaks ABI? Also
On Wed, Jul 14, 2021 at 11:29:08AM +0100, Robin Murphy wrote:
> As mentioned yesterday, already done! I'm hoping to be able to post the
> patches next week after some testing :)
Great, looking forward to your patches :-)
___
iommu mailing list
iommu@lis
Pass the max opt iova len to init the IOVA domain, if set.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index b540b586fe37..eee9f5f87935 100644
--- a
Add max opt argument to init_iova_domain(), and use it to set the rcaches
range.
Also fix up all users to set this value (at 0, meaning use default).
Signed-off-by: John Garry
---
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/host1x/dev.c | 2 +-
drivers/iommu/d
Add support to allow the maximum optimised DMA len be set for an IOMMU
group via sysfs.
This much the same with the method to change the default domain type for a
group.
Signed-off-by: John Garry
---
.../ABI/testing/sysfs-kernel-iommu_groups | 16 ++
drivers/iommu/iommu.c
Allow iommu_change_dev_def_domain() to create a new default domain, keeping
the same as current when type is unset.
Also remove comment about function purpose, which will become stale.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 54 ++-
1 file c
Some LLDs may request DMA mappings whose IOVA length exceeds that of the
current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the RB tree per DMA mapping cycle.
This has a significant effect on performance, more s
Function iommu_group_store_type() supports changing the default domain
of an IOMMU group.
Many conditions need to be satisfied and steps taken for this action to be
successful.
Satisfying these conditions and steps will be required for setting other
IOMMU group attributes, so factor into a common
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This may be much more pronounced from commit 4e89dce72521 ("iommu/iova:
Retry from last rb tree node if iova search fails"
On Mon, Jul 12, 2021 at 12:12:32PM +0200, Benjamin Gaignard wrote:
> Restore bits 39 to 32 at correct position.
> It reverses the operation done in rk_dma_addr_dte_v2().
>
> Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2")
>
> Reported-by: Dan Carpenter
> Signed-off-by: Benjamin
On Mon, Jul 12, 2021 at 03:17:12PM +0800, Lu Baolu wrote:
> drivers/iommu/intel/iommu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.o
On Mon, Jul 12, 2021 at 03:13:15PM +0800, Lu Baolu wrote:
> ---
> drivers/iommu/intel/iommu.c | 31 ++-
> 1 file changed, 22 insertions(+), 9 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.o
On 2021-07-14 11:15, Joerg Roedel wrote:
Hi Robin,
On Fri, Jul 09, 2021 at 02:56:47PM +0100, Robin Murphy wrote:
As I mentioned before, conceptually I think this very much belongs in sysfs
as a user decision. We essentially have 4 levels of "strictness":
1: DMA domain with bounce pages
2: DMA
On Tue, Jul 13, 2021 at 07:57:40PM -0400, Konrad Rzeszutek Wilk wrote:
> The SWIOTLB does have support to do late initialization (xen-pcifront
> does that for example - so if you add devices that can't do 64-bit it
> will allocate something like 4MB).
That sounds like a way to evaluate. I suggest
Hi Robin,
On Fri, Jul 09, 2021 at 02:56:47PM +0100, Robin Murphy wrote:
> As I mentioned before, conceptually I think this very much belongs in sysfs
> as a user decision. We essentially have 4 levels of "strictness":
>
> 1: DMA domain with bounce pages
> 2: DMA domain
> 3: DMA domain with flush
On Wed, Jul 14, 2021 at 05:41:54PM +0800, Jason Wang wrote:
>
> 在 2021/7/14 下午4:05, Dan Carpenter 写道:
> > On Wed, Jul 14, 2021 at 10:14:32AM +0800, Jason Wang wrote:
> > > 在 2021/7/13 下午7:31, Dan Carpenter 写道:
> > > > On Tue, Jul 13, 2021 at 04:46:52PM +0800, Xie Yongji wrote:
> > > > > @@ -613,37
在 2021/7/14 下午4:05, Dan Carpenter 写道:
On Wed, Jul 14, 2021 at 10:14:32AM +0800, Jason Wang wrote:
在 2021/7/13 下午7:31, Dan Carpenter 写道:
On Tue, Jul 13, 2021 at 04:46:52PM +0800, Xie Yongji wrote:
@@ -613,37 +618,28 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64
iova, u64 size)
在 2021/7/14 下午2:49, Yongji Xie 写道:
On Wed, Jul 14, 2021 at 1:45 PM Jason Wang wrote:
在 2021/7/13 下午4:46, Xie Yongji 写道:
This VDUSE driver enables implementing software-emulated vDPA
devices in userspace. The vDPA device is created by
ioctl(VDUSE_CREATE_DEV) on /dev/vduse/control. Then a char
Hi,
sorry this (or the 2 depency-series) cause a NULL Pointer deref in
iommu_group_remove_device on mt7623/bpi-r2
i wonder why on bootup a cleanup is run, but have no hint about this.
since "dts: mtk-mdp: remove mediatek, vpu property from primary MDP device" all
is good, i guess problem comes
在 2021/7/14 下午2:47, Greg KH 写道:
On Wed, Jul 14, 2021 at 02:02:50PM +0800, Jason Wang wrote:
在 2021/7/14 下午1:54, Michael S. Tsirkin 写道:
On Wed, Jul 14, 2021 at 01:45:39PM +0800, Jason Wang wrote:
+static int vduse_dev_msg_sync(struct vduse_dev *dev,
+ struct vduse_d
Hi
Thanks for the patchset.
I tested it on mt8173 (elm) with chromeos userspace.
Before that patchset, the test:
tast -verbose run -build=false 10.42.0.175 video.DecodeAccel.h264
sometimes passed and sometimes failed with 'context deadline exceeded'.
With this patchset it seems that the test a
On 14.07.21 10:13, Dafna Hirschfeld wrote:
Hi,
thanks for the patch
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
aut
On 14.07.21 04:56, Yong Wu wrote:
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_g
Hi Rob,
Thank you for the patch.
On Tue, Jul 13, 2021 at 01:34:53PM -0600, Rob Herring wrote:
> Another round of removing redundant minItems/maxItems from new schema in
> the recent merge window.
>
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the l
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
R
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_i
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec
Hi,
thanks for the patch
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the
On Wed, Jul 14, 2021 at 10:14:32AM +0800, Jason Wang wrote:
>
> 在 2021/7/13 下午7:31, Dan Carpenter 写道:
> > On Tue, Jul 13, 2021 at 04:46:52PM +0800, Xie Yongji wrote:
> > > @@ -613,37 +618,28 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v,
> > > u64 iova, u64 size)
> > > }
> > >
68 matches
Mail list logo