> On Jun 15, 2021, at 12:20 PM, Robin Murphy wrote:
>
> On 2021-06-15 19:14, Nadav Amit wrote:
>>> On Jun 15, 2021, at 5:55 AM, Robin Murphy wrote:
>>>
>>> On 2021-06-07 19:25, Nadav Amit wrote:
From: Nadav Amit
AMD's IOMMU can flush efficiently (i.e., in a single flush) any
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:59 AM
>
> On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 16, 2021 7:41 AM
> > >
> > > On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> > >
> > > > which
On 2021/6/15 19:55, Will Deacon wrote:
> On Tue, Jun 15, 2021 at 12:51:38PM +0100, Robin Murphy wrote:
>> On 2021-06-15 12:34, Will Deacon wrote:
>>> On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote:
On 2021/6/11 18:32, Will Deacon wrote:
> On Wed, Jun
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> Just noticed that after propagating swiotlb_force setting into
> io_tlb_default_mem->force, the memory allocation behavior for
> swiotlb_force will change (i.e. always skipping arch_dma_alloc and
> dma_direct_alloc_from_pool).
Yes, I
On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
>
> On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > Just noticed that after propagating swiotlb_force setting into
> > io_tlb_default_mem->force, the memory allocation behavior for
> > swiotlb_force will change (i.e.
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
include/linux/swiotlb.h | 11 +++
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
On Wed, Jun 16, 2021 at 11:54 AM Claire Chang wrote:
>
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> another
On Wed, Jun 16, 2021 at 01:10:02PM +0800, Claire Chang wrote:
> On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > > Just noticed that after propagating swiotlb_force setting into
> > > io_tlb_default_mem->force, the
v11 https://lore.kernel.org/patchwork/cover/1447216/
On Tue, Jun 15, 2021 at 9:27 PM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:02 AM
>
> On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, June 15, 2021 11:07 PM
> > >
> > > On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > > > Hi, Jason,
>
> From: Jason Gunthorpe
> Sent: Wednesday, June 16, 2021 7:41 AM
>
> On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
>
> > which information can you elaborate? This is the area which I'm not
> > familiar with thus would appreciate if you can help explain how this
> > bus specific
On Tue, Jun 15, 2021 at 07:21:35PM +0100, Will Deacon wrote:
> On Tue, Jun 15, 2021 at 06:12:13PM +, Krishna Reddy wrote:
> > > if (smmu->impl->probe_finalize)
> >
> > The above is the issue. It should be updated as below similar to other
> > instances impl callbacks.
> > if (smmu->impl &&
On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, June 15, 2021 11:07 PM
> >
> > On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > > Hi, Jason,
> > >
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, June 3, 2021 9:05 PM
On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, June 16, 2021 7:41 AM
> >
> > On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> >
> > > which information can you elaborate? This is the area which I'm not
> > > familiar
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> which information can you elaborate? This is the area which I'm not
> familiar with thus would appreciate if you can help explain how this
> bus specific information is utilized within the attach function or
> sometime later.
This
On 2021-06-15 19:26, Nadav Amit wrote:
On Jun 15, 2021, at 6:08 AM, Robin Murphy wrote:
On 2021-06-07 19:25, Nadav Amit wrote:
From: Nadav Amit
Do not use flush-queue on virtualized environments, where the NpCache
capability of the IOMMU is set. This is required to reduce
virtualization
> From: Jason Gunthorpe
> Sent: Tuesday, June 15, 2021 11:07 PM
>
> On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > Hi, Jason,
> >
> > > From: Jason Gunthorpe
> > > Sent: Thursday, June 3, 2021 9:05 PM
> > >
> > > On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> >
On 6/14/21 10:57 PM, Robin Murphy wrote:
Consolidating the flush queue logic also meant that the "iommu.strict"
option started taking effect on x86 as well. Make sure we document that.
Fixes: a250c23f15c2 ("iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE")
Signed-off-by: Robin Murphy
---
Hi Christoph,
On 14.06.2021 17:36, Christoph Hellwig wrote:
> On Mon, Jun 14, 2021 at 04:34:05PM +0100, Robin Murphy wrote:
>>> Looking at the rmem_dma_device_init() -> dma_init_coherent_memory(), it
>>> ends up calling memremap(MEMREMAP_WC) which would warn if it intersects
>>> with system RAM
Hi John,
On 6/14/21 4:03 PM, John Garry wrote:
On 12/06/2021 03:14, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2a71347611d4..4467353f981b 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -94,6 +94,7
Hi Krishna,
On 2021-06-14 23:18, Krishna Reddy wrote:
Right but we won't know until we profile the specific usecases or try
them in
generic workload to see if they affect the performance. Sure, over
invalidation is
a concern where multiple buffers can be mapped to same context and the
cache
On 2021-06-15 12:34, Will Deacon wrote:
On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote:
On 2021/6/11 18:32, Will Deacon wrote:
On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei wrote:
Fixes scripts/checkpatch.pl warning:
WARNING: Possible unnecessary 'out of memory'
On Tue, Jun 15, 2021 at 09:27:03PM +0800, Claire Chang wrote:
> Update is_swiotlb_buffer to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:04PM +0800, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:05PM +0800, Claire Chang wrote:
> Propagate the swiotlb_force setting into io_tlb_default_mem->force and
> use it to determine whether to bounce the data or not. This will be
> useful later to allow for different pools.
>
> Signed-off-by: Claire Chang
Looks good,
On Tue, Jun 15, 2021 at 12:51:38PM +0100, Robin Murphy wrote:
> On 2021-06-15 12:34, Will Deacon wrote:
> > On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote:
> > >
> > >
> > > On 2021/6/11 18:32, Will Deacon wrote:
> > > > On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei
On 2021-06-07 19:25, Nadav Amit wrote:
From: Nadav Amit
AMD's IOMMU can flush efficiently (i.e., in a single flush) any range.
This is in contrast, for instnace, to Intel IOMMUs that have a limit on
the number of pages that can be flushed in a single flush. In addition,
AMD's IOMMU do not
v10 here: https://lore.kernel.org/patchwork/cover/1446882/
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Jun 15, 2021 at 09:27:06PM +0800, Claire Chang wrote:
> Rename find_slots to swiotlb_find_slots and move the maintenance of
> alloc_size to it for better code reusability later.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Jun 15, 2021 at 09:27:08PM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a
On Tue, Jun 15, 2021 at 09:27:09PM +0800, Claire Chang wrote:
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
>
On Mon, 2021-06-07 at 11:25 -0700, Nadav Amit wrote:
> From: Robin Murphy
>
> The Mediatek driver is not the only one which might want a basic
> address-based gathering behaviour, so although it's arguably simple
> enough to open-code, let's factor it out for the sake of cleanliness.
> Let's
On 2021-06-15 13:29, Yong Wu wrote:
On Mon, 2021-06-07 at 11:25 -0700, Nadav Amit wrote:
From: Robin Murphy
The Mediatek driver is not the only one which might want a basic
address-based gathering behaviour, so although it's arguably simple
enough to open-code, let's factor it out for the
On 2021-06-07 19:25, Nadav Amit wrote:
From: Nadav Amit
Do not use flush-queue on virtualized environments, where the NpCache
capability of the IOMMU is set. This is required to reduce
virtualization overheads.
This change follows a similar change to Intel's VT-d and a detailed
explanation as
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files changed, 12 insertions(+), 4
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
kernel/dma/direct.c |
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
kernel/dma/direct.c | 2 +-
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Jun 15, 2021 at 09:27:00PM +0800, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
On Tue, Jun 15, 2021 at 09:27:01PM +0800, Claire Chang wrote:
> Split the debugfs creation to make the code reusable for supporting
> different bounce buffer pools.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu
Hi, Jason,
> From: Jason Gunthorpe
> Sent: Thursday, June 3, 2021 9:05 PM
>
> On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > > Two helper functions are provided to support VFIO_ATTACH_IOASID:
> > > >
> > > > struct attach_info {
> > > > u32 ioasid;
On Fri, Jun 11, 2021 at 09:50:31AM -0700, Nadav Amit wrote:
>
>
> > On Jun 11, 2021, at 6:57 AM, Will Deacon wrote:
> >
> > On Mon, Jun 07, 2021 at 11:25:39AM -0700, Nadav Amit wrote:
> >> From: Nadav Amit
> >>
> >> Refactor iommu_iotlb_gather_add_page() and factor out the logic that
> >>
On 2021-06-07 19:25, Nadav Amit wrote:
From: Robin Murphy
The Mediatek driver is not the only one which might want a basic
address-based gathering behaviour, so although it's arguably simple
enough to open-code, let's factor it out for the sake of cleanliness.
Let's also take this opportunity
On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2021/6/11 18:32, Will Deacon wrote:
> > On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei wrote:
> >> Fixes scripts/checkpatch.pl warning:
> >> WARNING: Possible unnecessary 'out of memory' message
> >>
> >> Remove
On 2021-06-15 08:26, Lu Baolu wrote:
Hi John,
On 6/14/21 4:03 PM, John Garry wrote:
On 12/06/2021 03:14, Lu Baolu wrote:
On 2021/6/11 20:20, John Garry wrote:
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2a71347611d4..4467353f981b 100644
--- a/drivers/iommu/Kconfig
+++
On Tue, Jun 15, 2021 at 12:34:17PM +0100, Will Deacon wrote:
> On Tue, Jun 15, 2021 at 07:22:10PM +0800, Leizhen (ThunderTown) wrote:
> >
> >
> > On 2021/6/11 18:32, Will Deacon wrote:
> > > On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei wrote:
> > >> Fixes scripts/checkpatch.pl warning:
> >
On 2021/6/11 18:32, Will Deacon wrote:
> On Wed, Jun 09, 2021 at 08:54:38PM +0800, Zhen Lei wrote:
>> Fixes scripts/checkpatch.pl warning:
>> WARNING: Possible unnecessary 'out of memory' message
>>
>> Remove it can help us save a bit of memory.
>>
>> Signed-off-by: Zhen Lei
>> ---
>>
On Mon, Jun 14, 2021 at 6:51 PM Shameerali Kolothum Thodi
wrote:
>
>
>
> > -Original Message-
> > From: Robin Murphy [mailto:robin.mur...@arm.com]
> > Sent: 14 June 2021 11:06
> > To: Shameerali Kolothum Thodi ;
> > linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> >
On 2021-06-07 19:25, Nadav Amit wrote:
From: Nadav Amit
On virtual machines, software must flush the IOTLB after each page table
entry update.
The iommu_map_sg() code iterates through the given scatter-gather list
and invokes iommu_map() for each element in the scatter-gather list,
which
On Tue, 15 Jun 2021 02:31:39 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Tuesday, June 15, 2021 12:28 AM
> >
> [...]
> > > IOASID. Today the group fd requires an IOASID before it hands out a
> > > device_fd. With iommu_fd the device_fd will not allow IOCTLs until it
> > >
On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> Hi, Jason,
>
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 9:05 PM
> >
> > On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > > > Two helper functions are provided to support VFIO_ATTACH_IOASID:
> > > > >
On 6/14/2021 11:32 PM, Christoph Hellwig wrote:
On Mon, Jun 14, 2021 at 02:49:51PM +0100, Robin Murphy wrote:
FWIW, I think a better generalisation for this would be allowing
set_memory_decrypted() to return an address rather than implicitly
operating in-place, and hide all the various
This VDUSE driver enables implementing vDPA devices in userspace.
The vDPA device's control path is handled in kernel and the data
path is handled in userspace.
A message mechnism is used by VDUSE driver to forward some control
messages such as starting/stopping datapath to userspace. Userspace
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 +
This series introduces a framework that makes it possible to implement
software-emulated vDPA devices in userspace. And to make it simple, the
emulated vDPA device's control path is handled in the kernel and only the
data path is implemented in the userspace.
Since the emuldated vDPA device's
Export alloc_iova_fast() and free_iova_fast() so that
some modules can use it to improve iova allocation efficiency.
Signed-off-by: Xie Yongji
---
drivers/iommu/iova.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index
The upcoming patch is going to support VA mapping/unmapping.
So let's factor out the logic of PA mapping/unmapping firstly
to make the code more readable.
Suggested-by: Jason Wang
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
---
drivers/vhost/vdpa.c | 53
This patch introduces an attribute for vDPA device to indicate
whether virtual address can be used. If vDPA device driver set
it, vhost-vdpa bus driver will not pin user page and transfer
userspace virtual address instead of physical address during
DMA mapping. And corresponding vma->vm_file and
Add an opaque pointer for vhost IOTLB. And introduce
vhost_iotlb_add_range_ctx() to accept it.
Suggested-by: Jason Wang
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
---
drivers/vhost/iotlb.c | 20
include/linux/vhost_iotlb.h | 3 +++
2 files changed, 19
Add an opaque pointer for DMA mapping.
Suggested-by: Jason Wang
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 6 +++---
drivers/vhost/vdpa.c | 2 +-
include/linux/vdpa.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
This implements an MMU-based IOMMU driver to support mapping
kernel dma buffer into userspace. The basic idea behind it is
treating MMU (VA->PA) as IOMMU (IOVA->PA). The driver will set
up MMU mapping instead of IOMMU mapping for the DMA transfer so
that the userspace process is able to use its
Export receive_fd() so that some modules can use
it to pass file descriptor between processes without
missing any security stuffs.
Signed-off-by: Xie Yongji
---
fs/file.c| 6 ++
include/linux/file.h | 7 +++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git
Increase the recursion depth of eventfd_signal() to 1. This
is the maximum recursion depth we have found so far, which
can be triggered with the following call chain:
kvm_io_bus_write[kvm]
--> ioeventfd_write [kvm]
--> eventfd_signal
On 6/14/2021 11:33 PM, Christoph Hellwig wrote:
On Mon, Jun 14, 2021 at 10:04:06PM +0800, Tianyu Lan wrote:
The pages in the hv_page_buffer array here are in the kernel linear
mapping. The packet sent to host will contain an array which contains
transaction data. In the isolation VM, data in
On 2021-06-15 12:51, Sai Prakash Ranjan wrote:
Hi Krishna,
On 2021-06-14 23:18, Krishna Reddy wrote:
Right but we won't know until we profile the specific usecases or try
them in
generic workload to see if they affect the performance. Sure, over
invalidation is
a concern where multiple
From: Will Deacon
The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
intended to describe the alignment requirements to consider when
choosing an appropriate page size. On the iommu_map() path, this address
is the logical OR of the virtual and physical addresses.
Subsequent
From: "Isaac J. Manjarres"
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can
call into the io-pgtable code, to map a physically contiguous
rnage of pages of the same size.
For IOMMU drivers that do not specify a map_pages()
From: "Isaac J. Manjarres"
Implement the map_pages() callback for the ARM LPAE io-pgtable
format.
Signed-off-by: Isaac J. Manjarres
Signed-off-by: Georgi Djakov
---
drivers/iommu/io-pgtable-arm.c | 41 +++--
1 file changed, 31 insertions(+), 10
On 2021-06-15 19:01, Marek Szyprowski wrote:
Hi,
On 03.06.2021 18:46, Thierry Reding wrote:
From: Thierry Reding
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
> if (smmu->impl->probe_finalize)
The above is the issue. It should be updated as below similar to other
instances impl callbacks.
if (smmu->impl && smmu->impl->probe_finalize)
-KR
___
iommu mailing list
iommu@lists.linux-foundation.org
> On Jun 15, 2021, at 5:55 AM, Robin Murphy wrote:
>
> On 2021-06-07 19:25, Nadav Amit wrote:
>> From: Nadav Amit
>> AMD's IOMMU can flush efficiently (i.e., in a single flush) any range.
>> This is in contrast, for instnace, to Intel IOMMUs that have a limit on
>> the number of pages that
On Tue, 15 Jun 2021 01:21:35 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Monday, June 14, 2021 9:38 PM
> >
> > On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
> >
> > > If a device can be always blocked from accessing memory in the IOMMU
> > > before it's
From: "Isaac J. Manjarres"
Mapping memory into io-pgtables follows the same semantics
that unmapping memory used to follow (i.e. a buffer will be
mapped one page block per call to the io-pgtable code). This
means that it can be optimized in the same way that unmapping
memory was, so add a
From: "Isaac J. Manjarres"
The PTE methods currently operate on a single entry. In preparation
for manipulating multiple PTEs in one map or unmap call, allow them
to handle multiple PTEs.
Signed-off-by: Isaac J. Manjarres
Suggested-by: Robin Murphy
Signed-off-by: Georgi Djakov
---
From: "Isaac J. Manjarres"
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can call
into the io-pgtable code, to unmap a virtually contiguous
range of pages of the same size.
For IOMMU drivers that do not specify an unmap_pages()
From: "Isaac J. Manjarres"
Implement the map_pages() callback for the ARM SMMU driver
to allow calls from iommu_map to map multiple pages of
the same size in one call. Also, remove the map() callback
for the ARM SMMU driver, as it will no longer be used.
Signed-off-by: Isaac J. Manjarres
1 - 100 of 119 matches
Mail list logo
