I have tried to set it once at probe and then leave it in place, however
the NVMe driver does not seem to like it, and the VM does not boot
correctly. I have spent a couple days debugging but I am a bit lost
now.
Basically whenever nvme_setup_prp_simple
On Wed, 27 Jan 2021 16:29:28 +, Robin Murphy wrote:
> The core API can now accommodate invalidate-on-map style behaviour in a
> single efficient call, so hook that up instead of having io-pgatble do
> it piecemeal.
Applied to arm64 (for-joerg/mtk), thanks!
[1/2] iommu/msm: Hook up
On Wed, Jan 27, 2021 at 05:39:16PM +0800, Yong Wu wrote:
> On Tue, 2021-01-26 at 22:23 +, Will Deacon wrote:
> > On Mon, Jan 11, 2021 at 07:18:48PM +0800, Yong Wu wrote:
> > > If group->default_domain exists, avoid reallocate it.
> > >
> > > In some iommu drivers, there may be several devices
On Thu, Jan 28, 2021 at 09:10:20PM +, Will Deacon wrote:
> On Wed, Jan 27, 2021 at 05:39:16PM +0800, Yong Wu wrote:
> > On Tue, 2021-01-26 at 22:23 +, Will Deacon wrote:
> > > On Mon, Jan 11, 2021 at 07:18:48PM +0800, Yong Wu wrote:
> > > > If group->default_domain exists, avoid reallocate
On Wed, Jan 27, 2021 at 07:32:55PM +0800, Zhen Lei wrote:
> v2 --> v3:
> Patch 3 is updated because https://lkml.org/lkml/2021/1/22/532 has been
> queued in advance.
>
> v1 --> v2:
> According to Robin Murphy's suggestion: https://lkml.org/lkml/2021/1/20/470
> Don't reserve the PMCG register
On Wed, Jan 27, 2021 at 04:38:26PM -0800, Jianxiong Gao wrote:
> NVMe driver and other applications may depend on the data offset
> to operate correctly. Currently when unaligned data is mapped via
> SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. This
> patch adds an option to make
On Thu, Jan 14, 2021 at 05:04:00PM +0800, Lu Baolu wrote:
> This adds a new trace event to track the submissions of requests to the
> invalidation queue. This event will provide the information like:
> - IOMMU name
> - Invalidation type
> - Descriptor raw data
>
> A sample output like:
> |
On Tue, Jan 19, 2021 at 07:16:14PM +0800, Lianbo Jiang wrote:
> Lianbo Jiang (2):
> dma-iommu: use static-key to minimize the impact in the fast-path
> iommu: use the __iommu_attach_device() directly for deferred attach
>
> drivers/iommu/dma-iommu.c | 29 +++--
>
On Fri, Jan 15, 2021 at 08:42:02AM +0800, Lu Baolu wrote:
> The Access/Dirty bits in the first level page table entry will be set
> whenever a page table entry was used for address translation or write
> permission was successfully translated. This is always true when using
> the first-level page
On Thu, Jan 14, 2021 at 04:50:21PM +0800, Lu Baolu wrote:
> The pasid based IOTLB and devTLB invalidation code is duplicate in
> several places. Consolidate them by using the common helpers.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/pasid.c | 18 ++--
>
On 2021-01-28 21:14, Will Deacon wrote:
On Thu, Jan 28, 2021 at 09:10:20PM +, Will Deacon wrote:
On Wed, Jan 27, 2021 at 05:39:16PM +0800, Yong Wu wrote:
On Tue, 2021-01-26 at 22:23 +, Will Deacon wrote:
On Mon, Jan 11, 2021 at 07:18:48PM +0800, Yong Wu wrote:
If
On Thu, 2021-01-28 at 21:14 +, Will Deacon wrote:
> On Thu, Jan 28, 2021 at 09:10:20PM +, Will Deacon wrote:
> > On Wed, Jan 27, 2021 at 05:39:16PM +0800, Yong Wu wrote:
> > > On Tue, 2021-01-26 at 22:23 +, Will Deacon wrote:
> > > > On Mon, Jan 11, 2021 at 07:18:48PM +0800, Yong Wu
HI Christoph
Thanks for your comments
On Thu, Jan 28, 2021 at 4:09 PM Christoph Hellwig wrote:
>
> I just included this patch as-is, but here are a few comments:
>
> On Thu, Jan 28, 2021 at 03:58:37PM +0100, Christoph Hellwig wrote:
> > +static void uvc_urb_dma_sync(struct uvc_urb *uvc_urb,
On Wed, Jan 27, 2021 at 04:38:28PM -0800, Jianxiong Gao wrote:
> For devices that need to preserve address offset on mapping through
> swiotlb, this patch adds offset preserving based on page_offset_mask
> and keeps the offset if the mask is non zero. This is needed for
> device drivers like NVMe.
The error can't be fixed by just updating the NVMe driver.
The NVMe spec (and as pointed out by Chirstoph, some other drivers) rely on
the offset of address to copy data correctly. When data is mapped via
swiotlb,
the current implementation always copy the data at 2k/4k aligned address.
On Thu,
On Wed, Jan 27, 2021 at 04:38:28PM -0800, Jianxiong Gao wrote:
> For devices that need to preserve address offset on mapping through
> swiotlb, this patch adds offset preserving based on page_offset_mask
> and keeps the offset if the mask is non zero. This is needed for
> device drivers like NVMe.
On Thu, Jan 28, 2021 at 05:27:25PM +, Robin Murphy wrote:
> On 2021-01-28 00:38, Jianxiong Gao wrote:
>> Some devices rely on the address offset in a page to function
>> correctly (NVMe driver as an example). These devices may use
>> a different page size than the Linux kernel. The address
On Thu, Jan 28, 2021 at 4:03 PM Christoph Hellwig wrote:
>
> From: Ricardo Ribalda
>
> On architectures where the is no coherent caching such as ARM use the
> dma_alloc_noncontiguos API and handle manually the cache flushing using
> dma_sync_sgtable().
>
> With this patch on the affected
From: Christoph Hellwig
> Sent: 28 January 2021 14:59
>
> Add a helper to map memory allocated using dma_alloc_pages into
> a user address space, similar to the dma_alloc_attrs function for
> coherent allocations.
>
...
> +::
> +
> + int
> + dma_mmap_pages(struct device *dev, struct
On 2021-01-28 15:18, Keqian Zhu wrote:
On 2021/1/27 17:39, Robin Murphy wrote:
On 2021-01-27 07:36, Keqian Zhu wrote:
On 2021/1/27 10:01, Leizhen (ThunderTown) wrote:
On 2021/1/26 18:12, Will Deacon wrote:
On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote:
Now we probably
On 2021-01-28 00:38, Jianxiong Gao wrote:
Some devices rely on the address offset in a page to function
correctly (NVMe driver as an example). These devices may use
a different page size than the Linux kernel. The address offset
has to be preserved upon mapping, and in order to do so, we
need to
On Thu, Jan 28, 2021 at 12:15:28PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2021 at 04:38:28PM -0800, Jianxiong Gao wrote:
> > For devices that need to preserve address offset on mapping through
> > swiotlb, this patch adds offset preserving based on page_offset_mask
> > and keeps the
On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_sgtable().
With this patch on the affected architectures we can measure up to 20x
performance improvement in uvc_video_copy_data_work().
Eg:
On 2021-01-28 00:38, Jianxiong Gao wrote:
NVMe driver relies on the address offset to function properly.
This patch adds the offset preserve mask to NVMe driver when mapping
via dma_map_sg_attrs and unmapping via nvme_unmap_sg. The mask
depends on the page size defined by CC.MPS register of NVMe
On Thu, Jan 28, 2021 at 06:00:58PM +, Robin Murphy wrote:
> If it were possible for this to fail, you might leak the DMA mapping here.
> However if dev->dma_parms somehow disappeared since a dozen lines above
> then I think you've got far bigger problems anyway.
>
> That said, do you really
On 2021/1/29 0:17, Robin Murphy wrote:
> On 2021-01-28 15:18, Keqian Zhu wrote:
>>
>>
>> On 2021/1/27 17:39, Robin Murphy wrote:
>>> On 2021-01-27 07:36, Keqian Zhu wrote:
On 2021/1/27 10:01, Leizhen (ThunderTown) wrote:
>
>
> On 2021/1/26 18:12, Will Deacon wrote:
On 2021/1/28 7:46, Alex Williamson wrote:
> On Fri, 22 Jan 2021 17:26:35 +0800
> Keqian Zhu wrote:
>
>> vfio_sanity_check_pfn_list() is used to check whether pfn_list and
>> notifier are empty when remove the external domain, so it makes a
>> wrong assumption that only external domain will
On Tue, Jan 26, 2021 at 01:06:29PM +, Shameer Kolothum wrote:
> The device iommu probe/attach might have failed leaving dev->iommu
> to NULL and device drivers may still invoke these functions resulting
> a crash in iommu vendor driver code. Hence make sure we check that.
>
> Signed-off-by:
Refactor ipmmu_of_xlate() to improve readability/scalability.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 49 +-
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c
On Tue, Jan 19, 2021 at 12:35:00PM +0800, Lu Baolu wrote:
> An incorrect address mask is being used in the qi_flush_dev_iotlb_pasid()
> to check the address alignment. This leads to a lot of spurious kernel
> warnings:
>
> [ 485.837093] DMAR: Invalidate non-aligned address 7f76f47f9000, order 0
On Tue, Jan 26, 2021 at 07:53:35PM +0800, Lianbo Jiang wrote:
> Lianbo Jiang (2):
> dma-iommu: use static-key to minimize the impact in the fast-path
> iommu: use the __iommu_attach_device() directly for deferred attach
>
> drivers/iommu/dma-iommu.c | 29 +++--
>
Hi Chuck,
thanks for your optimizations!
On Wed, Jan 27, 2021 at 03:00:32PM -0500, Chuck Lever wrote:
> From: Yong Wu
>
> iotlb_sync_map allow IOMMU drivers tlb sync after completing the whole
> mapping. This patch adds iova and size as the parameters in it. then the
> IOMMU driver could flush
Add SDHI devices into devices_allowlist.
Signed-off-by: Yoshihiro Shimoda
---
drivers/iommu/ipmmu-vmsa.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 0bdf354..5715fbe 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++
I intend to add new SoC support in near the future, but before that,
I would like to refactor the ipmmu_of_xlate() to improve
readability/scalability. Also, adds SDHI devices into the allow list.
Yoshihiro Shimoda (2):
iommu/ipmmu-vmsa: refactor ipmmu_of_xlate()
iommu/ipmmu-vmsa: Allow SDHI
Hi Joerg,
On Thu, Jan 28, 2021 at 01:51:12PM +0100, Joerg Roedel wrote:
> On Wed, Jan 27, 2021 at 03:00:32PM -0500, Chuck Lever wrote:
> > From: Yong Wu
> >
> > iotlb_sync_map allow IOMMU drivers tlb sync after completing the whole
> > mapping. This patch adds iova and size as the parameters in
On Thu, Jan 28, 2021 at 01:19:29PM +, Will Deacon wrote:
> Heads-up, but I already queued this patch as part of its original series:
>
> https://lore.kernel.org/r/20210107122909.16317-1-yong...@mediatek.com
>
> since it's part of the Mediatek series for 5.12.
>
> Would you like me to drop
Hi all,
this series adds the new noncontiguous DMA allocation API requested by
various media driver maintainers.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
It turns out allowing non-contigous allocations here was a rather bad
idea, as we'll now need to define ways to get the pages for mmaping
or dma_buf sharing. Revert this change and stick to the original
concept. A different API for the use case of non-contigous allocations
will be added back
Add a helper to map memory allocated using dma_alloc_pages into
a user address space, similar to the dma_alloc_attrs function for
coherent allocations.
Signed-off-by: Christoph Hellwig
---
Documentation/core-api/dma-api.rst | 10 ++
include/linux/dma-mapping.h| 2 ++
Add a new API that returns a potentiall virtually non-contigous sg_table
and a DMA address. This API is only properly implemented for dma-iommu
and will simply return a contigious chunk as a fallback.
The intent is that media drivers can use this API if either:
- no kernel mapping or only
From: Ricardo Ribalda
On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_sgtable().
With this patch on the affected architectures we can measure up to 20x
performance improvement in
Split out a new helper that only allocates a sg_table worth of
memory without mapping it into contiguous kernel address space.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 66 +--
1 file changed, 35 insertions(+), 31 deletions(-)
diff
Implement support for allocating a non-contiguous DMA region.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
I just included this patch as-is, but here are a few comments:
On Thu, Jan 28, 2021 at 03:58:37PM +0100, Christoph Hellwig wrote:
> +static void uvc_urb_dma_sync(struct uvc_urb *uvc_urb, bool for_device)
> +{
> + struct device *dma_dev = dma_dev = stream_to_dmadev(uvc_urb->stream);
> +
> +
From: jiangkunkun
If HTTU is supported, we enable HA/HD bits in the SMMU CD (stage 1
mapping), and set DBM bit for writable TTD.
The dirty state information is encoded using the access permission
bits AP[2] (stage 1) or S2AP[1] (stage 2) in conjunction with the
DBM (Dirty Bit Modifier) bit,
From: jiangkunkun
Block descriptor is not a proper granule for dirty log tracking. This
adds a new interface named split_block in iommu layer and arm smmuv3
implements it, which splits block descriptor to an equivalent span of
page descriptors.
During spliting block, other interfaces are not
From: jiangkunkun
When altering a translation table descriptor of some specific reasons,
we require break-before-make procedure. But it might cause problems when
the TTD is alive. The I/O streams might not tolerate translation faults.
If the SMMU supports BBML level 1 or BBML level 2, we can
From: jiangkunkun
We have implemented these interfaces required to support iommu
dirty log tracking. The last step is reporting this feature to
upper user, then the user can perform higher policy base on it.
This adds a new dev feature named IOMMU_DEV_FEAT_HWDBM in iommu
layer. For arm smmuv3,
From: jiangkunkun
When stop dirty log tracking, we need to recover all block descriptors
which are splited when start dirty log tracking. This adds a new
interface named merge_page in iommu layer and arm smmuv3 implements it,
which reinstall block mappings and unmap the span of page mappings.
Hi all,
This patch series implement a new dirty log tracking method for vfio dma.
Intention：
As we know, vfio live migration is an important and valuable feature, but there
are still many hurdles to solve, including migration of interrupt, device state,
DMA dirty log tracking, and etc.
For
From: jiangkunkun
During dirty log tracking, user will try to retrieve dirty log from
iommu if it supports hardware dirty log. This adds a new interface
named sync_dirty_log in iommu layer and arm smmuv3 implements it,
which scans leaf TTD and treats it's dirty if it's writable (As we
just
From: jiangkunkun
We are going to optimize dirty log tracking based on iommu
HWDBM feature, but the dirty log from iommu is useful only
when all iommu backed groups are connected to iommu with
HWDBM feature. This maintains a counter for this feature.
Co-developed-by: Keqian Zhu
Signed-off-by:
From: jiangkunkun
In the past, we clear dirty log immediately after sync dirty
log to userspace. This may cause redundant dirty handling if
userspace handles dirty log iteratively:
After vfio clears dirty log, new dirty log starts to generate.
These new dirty log will be reported to userspace
From: jiangkunkun
In the past if vfio_iommu is not of pinned_page_dirty_scope and
vfio_dma is iommu_mapped, we populate full dirty bitmap for this
vfio_dma. Now we can try to get dirty log from iommu before make
the lousy decision.
Co-developed-by: Keqian Zhu
Signed-off-by: Kunkun Jiang
---
From: jiangkunkun
The SMMU which supports HTTU (Hardware Translation Table Update) can
update the access flag and the dirty state of TTD by hardware. It is
essential to track dirty pages of DMA.
This adds feature detection, none functional change.
Co-developed-by: Keqian Zhu
Signed-off-by:
On 2021/1/27 17:39, Robin Murphy wrote:
> On 2021-01-27 07:36, Keqian Zhu wrote:
>>
>>
>> On 2021/1/27 10:01, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2021/1/26 18:12, Will Deacon wrote:
On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote:
> Now we probably will need some
On 2021/1/28 7:46, Alex Williamson wrote:
> On Fri, 22 Jan 2021 17:26:35 +0800
> Keqian Zhu wrote:
>
>> vfio_sanity_check_pfn_list() is used to check whether pfn_list and
>> notifier are empty when remove the external domain, so it makes a
>> wrong assumption that only external domain will
From: jiangkunkun
After dirty log is retrieved, user should clear dirty log to re-enable
dirty log tracking for these dirtied pages. This adds a new interface
named clear_dirty_log and arm smmuv3 implements it, which clears the dirty
state (As we just enable HTTU for stage1, so set the AP[2]
On 2021-01-27 20:00, Chuck Lever wrote:
Hi-
This collection of patches seems to get the best throughtput results
so far. The NFS WRITE result is fully restored, and the NFS READ
result is very close to fully restored.
Children see throughput for 12 initial writers = 5008474.03 kB/sec
> On Jan 28, 2021, at 8:59 AM, Robin Murphy wrote:
>
> On 2021-01-27 20:00, Chuck Lever wrote:
>> Hi-
>> This collection of patches seems to get the best throughtput results
>> so far. The NFS WRITE result is fully restored, and the NFS READ
>> result is very close to fully restored.
>>
On Wed, Jan 27, 2021 at 03:00:53PM -0500, Chuck Lever wrote:
> From: Isaac J. Manjarres
>
> Implement the map_sg io-pgtable op for the ARM LPAE io-pgtable
> code, so that IOMMU drivers can call it when they need to map
> a scatter-gather list.
>
> Signed-off-by: Isaac J. Manjarres
> Tested-by:
61 matches
Mail list logo
