FYI, as of the last one I'm fine now, bit I really need an ACK from
the arm64 maintainers.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 8/20/20 7:26 PM, Barry Song wrote:
>
>
> Cc: Jonathan Cameron
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Ganapatrao Kulkarni
> Cc: Catalin Marinas
> Cc: Nicolas Saenz Julienne
> Cc: Steve Capper
> Cc: Andrew Morton
> Cc: Mike Rapoport
>
Right now, drivers like ARM SMMU are using dma_alloc_coherent() to get
coherent DMA buffers to save their command queues and page tables. As
there is only one default CMA in the whole system, SMMUs on nodes other
than node0 will get remote memory. This leads to significant latency.
This patch prov
Ganapatrao Kulkarni has put some effort on making arm-smmu-v3 use local
memory to save command queues[1]. I also did similar job in patch
"iommu/arm-smmu-v3: allocate the memory of queues in local numa node"
[2] while not realizing Ganapatrao has done that before.
But it seems it is much better to
Right now, smmu is using dma_alloc_coherent() to get memory to save queues
and tables. Typically, on ARM64 server, there is a default CMA located at
node0, which could be far away from node2, node3 etc.
with this patch, smmu will get memory from local numa node to save command
queues and page table
Hi Alex,
> From: Alex Williamson
> Sent: Friday, August 21, 2020 9:49 AM
>
> On Fri, 21 Aug 2020 00:37:19 +
> "Liu, Yi L" wrote:
>
> > Hi Alex,
> >
> > > From: Alex Williamson
> > > Sent: Friday, August 21, 2020 4:51 AM
> > >
> > > On Mon, 27 Jul 2020 23:27:36 -0700
> > > Liu Yi L wrote:
To allow utilizing the irq domain pointer in struct device it is necessary
to make XEN/MSI irq domain compatible.
While the right solution would be to truly convert XEN to irq domains, this
is an exercise which is not possible for mere mortals with limited XENology.
Provide a plain irqdomain wrap
Provide a helper function to check whether a PCI device is handled by a
non-standard PCI/MSI domain. This will be used to exclude such devices
which hang of a special bus, e.g. VMD, to be excluded from the irq domain
override in irq remapping.
Signed-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc:
Devices on the VMD bus use their own MSI irq domain, but it is not
distinguishable from regular PCI/MSI irq domains. This is required
to exclude VMD devices from getting the irq domain pointer set by
interrupt remapping.
Override the default bus token.
Signed-off-by: Thomas Gleixner
Cc: Bjorn He
Add device specific MSI domain infrastructure for devices which have their
own resource management and interrupt chip. These devices are not related
to PCI and contrary to platform MSI they do not share a common resource and
interrupt chip. They provide their own domain specific resource management
To support MSI irq domains which do not fit at all into the regular MSI
irqdomain scheme, like the XEN MSI interrupt management for PV/HVM/DOM0,
it's necessary to allow to override the alloc/free implementation.
This is a preperatory step to switch X86 away from arch_*_msi_irqs() and
store the irq
Retrieve the PCI device from the msi descriptor instead of doing so at the
call sites.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
---
arch/x86/kernel/apic/msi.c |2 +-
drivers/pci/msi.c | 13 ++---
include/linux/msi.h|3 +--
3 files changed, 8
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq
Get rid of all the gunk and enable CONFIG_PCI_MSI_DISABLE_ARCH_FALLBACKS.
Signed-off-by: Thomas Gleixner
Cc: xen-de...@lists.xenproject.org
Cc: linux-...@vger.kernel.org
---
arch/x86/Kconfig|1 +
arch/x86/include/asm/pci.h | 11 ---
arch/x86/include/asm/x86_ini
Now that interrupt remapping sets the irqdomain pointer when a PCI device
is added it's possible to store the default irq domain in the device struct
in pcibios_add_device().
If the bus to which a device is connected has an irq domain associated then
this domain is used otherwise the default domai
If an architecture does not require the MSI setup/teardown fallback
functions, then allow them to be replaced by stub functions which emit a
warning.
Signed-off-by: Thomas Gleixner
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/Kconfig |3 +++
drivers/pci/msi.c |3 ++-
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture in
the generic MSI header.
One arch specific function
For the upcoming device MSI support a new allocation type is
required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -40,6 +40,7 @@ enum irq_alloc_type {
Move the IOAPIC specific fields into their own struct and reuse the common
devid. Get rid of the #ifdeffery as it does not matter at all whether the
alloc info is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: "K. Y. Srinivasan"
Cc: Stephen Hemminger
Cc: Joerg
Adding a function call before the first #ifdef in arch_pci_init() triggers
a 'mixed declarations and code' warning if PCI_DIRECT is enabled.
Use stub functions and move the #ifdeffery to the header file where it is
not in the way.
Signed-off-by: Thomas Gleixner
Cc: linux-...@vger.kernel.org
---
pci_msi_get_hwirq() and pci_msi_set_desc are not longer special. Enable the
generic MSI domain ops in the core and PCI MSI code unconditionally and get
rid of the x86 specific implementations in the X86 MSI code and in the
hyperv PCI driver.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: Stephen
None of the magic HPET fields are required in any way.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Cc: Lu Baolu
---
arch/x86/include/asm/hw_irq.h |7 ---
arch/x86/kernel/apic/msi.c | 14 +++---
drivers/iommu/amd/iommu.c
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into an
irq domain.
Move the x86_msi ops setup into a single function to
As the next step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
It only overrides the irqdomain of devices which are handled by a regular
PCI/MSI irq domain which protects PCI devices behind special busses like
VM
For devices which don't have a standard storage for MSI messages like the
upcoming IMS (Interrupt Message Storm) it's required to allocate storage
space before allocating interrupts and after freeing them.
This could be achieved with the existing callbacks, but that would be
awkward because they o
Convert the interrupt remap drivers to retrieve the pci device from the msi
descriptor and use info::hwirq.
This is the first step to prepare x86 for using the generic MSI domain ops.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: Stephen Hemminger
Cc: Joerg Roedel
Cc: linux-...@vger.kernel.o
No point to call it from both 32bit and 64bit implementations of
default_setup_apic_routing(). Move it to the caller.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c |3 +++
arch/x86/kernel/apic/probe_32.c |3 ---
arch/x86/kernel/apic/probe_64.c |3 ---
3 files cha
struct irq_alloc_info is a horrible zoo of unnamed structs in a union. Many
of the struct fields can be generic and don't have to be type specific like
hpet_id, ioapic_id...
Provide a generic set of members to prepare for the consolidation. The goal
is to make irq_alloc_info have the same basic me
For the upcoming device MSI support it's required to have a default
irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
need to care.
Signed-off-by: Thomas Gleixner
Cc: Greg Kroah-Hartman
---
drivers/base/platform-msi.c |2 ++
1 file changed, 2 insertions(+)
--- a/driv
As a first step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
This is done from dmar_pci_bus_add_dev() because it has to work even when
DMA remapping is disabled. It only overrides the irqdomain of devices which
Dereferencing irq_data before checking it for NULL is suboptimal.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
---
drivers/iommu/amd/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/
No point in initializing the default PCI/MSI interrupt domain early and no
point to create it when XEN PV/HVM/DOM0 are active.
Move the initialization to pci_arch_init() and convert it to init ops so
that XEN can override it as XEN has it's own PCI/MSI management. The XEN
override comes in a later
Move the UV specific fields into their own struct for readability sake. Get
rid of the #ifdeffery as it does not matter at all whether the alloc info
is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
Cc: Steve Wahl
Cc: Dimitri Sivanich
Cc: Russ Anderson
---
arch/x86/include/
Now that the iommu implementations handle the X86_*_GET_PARENT_DOMAIN
types, consolidate the two getter functions.
Signed-off-by: Thomas Gleixner
Cc: Wei Liu
Cc: Joerg Roedel
Cc: linux-hyp...@vger.kernel.org
Cc: iommu@lists.linux-foundation.org
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Jo
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
arch_teardown_msi_irq(). default_teardown_msi_irqs() is a trivial it
PCI devices behind a VMD bus are not subject to interrupt remapping, but
the irq domain for VMD MSI cannot be distinguished from a regular PCI/MSI
irq domain.
Add a new domain bus token and allow it in the bus token check in
msi_check_reservation_mode() to keep the functionality the same once VMD
Nothing except XEN uses the setup/teardown ops. Hide them there.
Signed-off-by: Thomas Gleixner
Cc: xen-de...@lists.xenproject.org
Cc: linux-...@vger.kernel.org
---
arch/x86/include/asm/x86_init.h |2 --
arch/x86/pci/xen.c | 23 +++
2 files changed, 15 inse
A generic IMS irq chip and irq domain implementation for IMS based devices
which utilize a MSI message store array on chip.
Allows IMS devices with a MSI message store array to reuse this code for
different array sizes.
Allocation and freeing of interrupts happens via the generic
msi_domain_alloc
The only user is in the same file and the name is too generic because this
function is only ever used for HVM domains.
Signed-off-by: Thomas Gleixner
Cc: Konrad Rzeszutek Wilk
Cc: linux-...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Sta
Some past platform removal forgot to get rid of this unused ballast.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mpspec.h | 10 --
arch/x86/include/asm/x86_init.h | 10 --
arch/x86/kernel/mpparse.c | 26 --
arch/x86/kernel/x86_ini
No functional change.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
---
arch/x86/include/asm/hw_irq.h |4 ++--
arch/x86/kernel/apic/msi.c |6 +++---
drivers/iommu/amd/iommu.c | 24
drivers/iommu/i
First of all, sorry for the horrible long Cc list, which was
unfortunately unavoidable as this touches the world and some more.
This patch series aims to provide a base to support device MSI (non
PCI based) in a halfways architecture independent way.
It's a mixed bag of bug fixes, cleanups and ge
irq_remapping_ir_irq_domain() is used to retrieve the remapping parent
domain for an allocation type. irq_remapping_irq_domain() is for retrieving
the actual device domain for allocating interrupts for a device.
The two functions are similar and can be unified by using explicit modes
for parent ir
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Cc: Lu Baolu
---
drivers/iommu/intel/irq_remapping.c | 67 ---
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
---
drivers/iommu/amd/iommu.c | 65 ++
1 file
On Fri, 21 Aug 2020 00:37:19 +
"Liu, Yi L" wrote:
> Hi Alex,
>
> > From: Alex Williamson
> > Sent: Friday, August 21, 2020 4:51 AM
> >
> > On Mon, 27 Jul 2020 23:27:36 -0700
> > Liu Yi L wrote:
> >
> > > This patch allows userspace to request PASID allocation/free, e.g.
> > > when serv
Hi Alex,
> From: Alex Williamson
> Sent: Friday, August 21, 2020 5:49 AM
>
> On Mon, 27 Jul 2020 23:27:41 -0700
> Liu Yi L wrote:
>
> > Recent years, mediated device pass-through framework (e.g. vfio-mdev)
> > is used to achieve flexible device sharing across domains (e.g. VMs).
> > Also there
Hi Alex,
> From: Alex Williamson
> Sent: Friday, August 21, 2020 3:52 AM
>
> On Mon, 27 Jul 2020 23:27:33 -0700
> Liu Yi L wrote:
>
> > This patch exports iommu nesting capability info to user space through
> > VFIO. Userspace is expected to check this info for supported uAPIs (e.g.
> > PASID
Hi Alex,
> From: Alex Williamson
> Sent: Friday, August 21, 2020 4:51 AM
>
> On Mon, 27 Jul 2020 23:27:36 -0700
> Liu Yi L wrote:
>
> > This patch allows userspace to request PASID allocation/free, e.g.
> > when serving the request from the guest.
> >
> > PASIDs that are not freed by userspace
On 2020-08-20 21:16, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-gart.c | 17
Hi Alex,
> From: Alex Williamson
> Sent: Friday, August 21, 2020 5:06 AM
>
> On Mon, 27 Jul 2020 23:27:37 -0700
> Liu Yi L wrote:
>
> > From: Yi Sun
> >
> > Current interface is good enough for SVA virtualization on an assigned
> > physical PCI device, but when it comes to mediated devices, a
On 2020-08-20 20:51, Dmitry Osipenko wrote:
20.08.2020 18:08, Robin Murphy пишет:
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/staging/media/tegra-vde/iommu.c | 12 -
On 2020-08-20 20:55, Sakari Ailus wrote:
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma, devices
behi
On Mon, 27 Jul 2020 23:27:41 -0700
Liu Yi L wrote:
> Recent years, mediated device pass-through framework (e.g. vfio-mdev)
> is used to achieve flexible device sharing across domains (e.g. VMs).
> Also there are hardware assisted mediated pass-through solutions from
> platform vendors. e.g. Intel
The pull request you sent on Thu, 20 Aug 2020 18:41:58 +0200:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.9-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d271b51c60ebe71e0435a9059b315a3d8bb8a099
Thank you!
--
Deet-doot-dot, I am a bot.
On Mon, 27 Jul 2020 23:27:37 -0700
Liu Yi L wrote:
> From: Yi Sun
>
> Current interface is good enough for SVA virtualization on an assigned
> physical PCI device, but when it comes to mediated devices, a physical
> device may attached with multiple aux-domains. Also, for guest unbind,
s/may/m
On Mon, 27 Jul 2020 23:27:36 -0700
Liu Yi L wrote:
> This patch allows userspace 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: Ke
20.08.2020 18:08, Robin Murphy пишет:
> Now that arch/arm is wired up for default domains and iommu-dma,
> implement the corresponding driver-side support for DMA domains.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/tegra-gart.c | 17 -
> 1 file changed, 12 insertions(+
20.08.2020 22:51, Dmitry Osipenko пишет:
> Alternatively, the Tegra SMMU could be changed such that the devices
> will be attached to a domain at the time of a first IOMMU mapping
> invocation instead of attaching at the time of attach_dev() callback
> invocation.
>
> Or maybe even IOMMU core coul
On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
> On 2020-08-20 17:53, Sakari Ailus wrote:
> > Hi Robin,
> >
> > On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> > > Now that arch/arm is wired up for default domains and iommu-dma, devices
> > > behind IOMMUs will get m
On Mon, 27 Jul 2020 23:27:33 -0700
Liu Yi L wrote:
> This patch exports iommu nesting capability info to user space through
> VFIO. Userspace 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 info
20.08.2020 18:08, Robin Murphy пишет:
> Now that arch/arm is wired up for default domains and iommu-dma, we no
> longer need to work around the arch-private mapping.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/staging/media/tegra-vde/iommu.c | 12
> 1 file changed, 12 deletions(
On Thu, Aug 20, 2020 at 6:52 PM Christoph Hellwig wrote:
>
> On Thu, Aug 20, 2020 at 12:24:31PM +0200, Tomasz Figa wrote:
> > > Of course this still uses the scatterlist structure with its annoying
> > > mix of input and output parametes, so I'd rather not expose it as
> > > an official API at the
On Thu, Aug 20, 2020 at 6:54 PM Christoph Hellwig wrote:
>
> On Thu, Aug 20, 2020 at 12:05:29PM +0200, Tomasz Figa wrote:
> > The UAPI and V4L2/videobuf2 changes are in good shape and the only
> > wrong part is the use of DMA API, which was based on an earlier email
> > guidance anyway, and a chan
On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
Now that arch/arm is wired up for default domains and iommu-dma, devices
behind IOMMUs will get mappings set up automatically as appropriate, so
there is no need for drivers to do so
On Thu, Aug 20, 2020 at 9:58 AM Robin Murphy wrote:
>
> On 2020-08-20 16:55, Rob Clark wrote:
> > Side note, I suspect we'll end up needing something like
> > 0e764a01015dfebff8a8ffd297d74663772e248a .. if someone can dig a 32b
> > device out of the closet and dust it off, the fix is easy enough.
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> Now that arch/arm is wired up for default domains and iommu-dma, devices
> behind IOMMUs will get mappings set up automatically as appropriate, so
> there is no need for drivers to do so manually.
>
> Signed-off-by: Robin M
On 2020-08-20 16:55, Rob Clark wrote:
Side note, I suspect we'll end up needing something like
0e764a01015dfebff8a8ffd297d74663772e248a .. if someone can dig a 32b
device out of the closet and dust it off, the fix is easy enough.
Just wanted to mention that here so anyone with a 32b device could
On Thu, Aug 20, 2020 at 12:05:29PM +0200, Tomasz Figa wrote:
> The UAPI and V4L2/videobuf2 changes are in good shape and the only
> wrong part is the use of DMA API, which was based on an earlier email
> guidance anyway, and a change to the synchronization part . I find
> conclusions like the above
On Thu, Aug 20, 2020 at 12:24:31PM +0200, Tomasz Figa wrote:
> > Of course this still uses the scatterlist structure with its annoying
> > mix of input and output parametes, so I'd rather not expose it as
> > an official API at the DMA layer.
>
> The problem with the above open coded approach is t
On Thu, Aug 20, 2020 at 12:09:34PM +0200, Tomasz Figa wrote:
> > I'm happy to Cc and active participant in the discussion. I'm not
> > going to add all reviewers because even with the trimmed CC list
> > I'm already hitting the number of receipients limit on various lists.
>
> Fair enough.
>
> W
The following changes since commit a1d21081a60dfb7fddf4a38b66d9cef603b317a9:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2020-08-13
20:03:11 -0700)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.9-1
for you t
Side note, I suspect we'll end up needing something like
0e764a01015dfebff8a8ffd297d74663772e248a .. if someone can dig a 32b
device out of the closet and dust it off, the fix is easy enough.
Just wanted to mention that here so anyone with a 32b device could
find what is needed.
BR,
-R
On Thu, Au
With no users left and generic iommu-dma now doing all the work,
clean up the last traces of the arch-specific API, plus the temporary
workarounds that you'd forgotten about because you were thinking about
zebras instead.
Signed-off-by: Robin Murphy
---
arch/arm/common/dmabounce.c | 1 -
Now that arch/arm is wired up for default domains and iommu-dma, remove
the add_device workaround.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-s
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/msm_iommu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/msm_iommu.c b/driver
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-gart.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/tegra-
Now that arch/arm is wired up for default domains and iommu-dma, devices
behind IOMMUs will get mappings set up automatically as appropriate, so
there is no need for drivers to do so manually.
Signed-off-by: Robin Murphy
---
drivers/media/platform/omap3isp/isp.c | 68 ++-
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
Now that arch/arm is wired up for default domains and iommu-dma, we no
longer need to work around the arch-private mapping.
Signed-off-by: Robin Murphy
---
drivers/staging/media/tegra-vde/iommu.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/staging/media/tegra-vde/iom
Now that iommu-dma is wired up, we can let it work as normal
without the dma_iommu_mapping hacks if the IOMMU driver already
supports default domains.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/
Now that arch/arm is wired up for default domains and iommu-dma, we can
consolidate the shared mapping code onto the generic IOMMU API version,
and retire the arch-specific implementation.
Signed-off-by: Robin Murphy
---
This is a cheeky revert of 07dc3678bacc ("drm/exynos: Fix cleanup of
IOMMU
With the IOMMU ops now looking much the same shape as iommu_dma_ops,
switch them out in favour of the iommu-dma library, currently enhanced
with temporary workarounds that allow it to also sit underneath the
arch-specific API. With that in place, we can now start converting the
remaining IOMMU driv
Now that arch/arm is wired up for default domains and iommu-dma, remove
the shared mapping workaround and rely on groups there as well.
Signed-off-by: Robin Murphy
---
drivers/iommu/ipmmu-vmsa.c | 69 --
1 file changed, 69 deletions(-)
diff --git a/drivers/io
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-smmu.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for groups and DMA
domains to replace the shared mapping workaround.
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.h| 2 -
drivers/iommu/mtk_iommu_v1.c | 153 +
Now that arch/arm is wired up for default domains and iommu-dma,
implement the corresponding driver-side support for DMA domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/omap-iommu.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/om
The dma_sync_* operations are now the only difference between the
coherent and non-coherent IOMMU ops. Some minor tweaks to make those
safe for coherent devices with minimal overhead, and we can condense
down to a single set of DMA ops.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c |
In order to wrangle arch/arm over to iommu_dma_ops, we first need to
convert all its associated IOMMU drivers over to default domains, and
deal with users of its public dma_iommu_mappinng API. Since that can't
reasonably be done in a single patch, we've no choice but to go through
an ugly transitio
Hi all,
After 5 years or so of intending to get round to this, finally the
time comes! The changes themselves actualy turn out to be relatively
mechanical; the bigger concern appears to be how to get everything
merged across about 5 diffferent trees given the dependencies.
I've lightly boot-teste
When an IOMMU is present, we trust that it should be capable
of remapping any physical memory, and since the device masks
represent the input (virtual) addresses to the IOMMU it makes
no sense to validate them against physical PFNs anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
---
arch/arm/Kconfig | 4 +-
arch/arm/mm/dma-mapping.c | 281 +++---
Hi Anday,
On Tue, Aug 18, 2020 at 4:14 AM Andy Shevchenko
wrote:
>
> On Mon, Aug 17, 2020 at 05:53:09PM -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 ad
On 2020-08-19 00:38, Barry Song wrote:
patch 1/3 and patch 2/3 are the preparation of patch 3/3 which permits users
to disable MSI-based polling by cmd line.
-v4:
with respect to Robin's comments
* cleanup the code of the existing module parameter disable_bypass
* add ARM_SMMU_OPT_MSIPO
From: Vijayanand Jitta
When ever an iova alloc request fails we free the iova
ranges present in the percpu iova rcaches and then retry
but the global iova rcache is not freed as a result we could
still see iova alloc failure even after retry as global
rcache is holding the iova's which can cause
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the cached node iova allocation can still fail
because of thi
On Thu, Aug 20, 2020 at 7:02 AM Christoph Hellwig wrote:
>
> On Wed, Aug 19, 2020 at 03:07:04PM +0100, Robin Murphy wrote:
> >> FWIW, I asked back in time what the plan is for non-coherent
> >> allocations and it seemed like DMA_ATTR_NON_CONSISTENT and
> >> dma_sync_*() was supposed to be the righ
On Thu, Aug 20, 2020 at 6:45 AM Christoph Hellwig wrote:
>
> On Wed, Aug 19, 2020 at 04:11:52PM +0200, Tomasz Figa wrote:
> > > > By the way, as a videobuf2 reviewer, I'd appreciate being CC'd on any
> > > > series related to the subsystem-facing DMA API changes, since
> > > > videobuf2 is one of
On Thu, Aug 20, 2020 at 7:20 AM Christoph Hellwig wrote:
>
> On Thu, Aug 20, 2020 at 06:43:47AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 19, 2020 at 03:57:53PM +0200, Tomasz Figa wrote:
> > > > > Could you explain what makes you think it's unused? It's a feature of
> > > > > the UAPI genera
99 matches
Mail list logo
