Re: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
Hi,
On 12/16/18 6:38 AM, Liu, Yi L wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Sunday, November 11, 2018 10:45 PM
Subject: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
This adds APIs for IOMMU drivers and device drivers to manage the PASIDs used
for
DMA transfer and translation. It bases on I/O ASID allocator for PASID namespace
management and relies on vendor specific IOMMU drivers for paravirtual PASIDs.
Below APIs are added:
* iommu_pasid_init(pasid)
- Initialize a PASID consumer. The vendor specific IOMMU
drivers are able to set the PASID range imposed by IOMMU
hardware through a callback in iommu_ops.
* iommu_pasid_exit(pasid)
- The PASID consumer stops consuming any PASID.
* iommu_pasid_alloc(pasid, min, max, private, *ioasid)
- Allocate a PASID and associate a @private data with this
PASID. The PASID value is stored in @ioaisd if returning
success.
* iommu_pasid_free(pasid, ioasid)
- Free a PASID to the pool so that it could be consumed by
others.
This also adds below helpers to lookup or iterate PASID items associated with a
consumer.
* iommu_pasid_for_each(pasid, func, data)
- Iterate PASID items of the consumer identified by @pasid,
and call @func() against each item. An error returned from
@func() will break the iteration.
* iommu_pasid_find(pasid, ioasid)
- Retrieve the private data associated with @ioasid.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Jean-Philippe Brucker
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/iommu.c | 89 +++
include/linux/iommu.h | 73 +++
3 files changed, 163 insertions(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index
d9a25715650e..39f2bb76c7b8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -1,6 +1,7 @@
# IOMMU_API always gets selected by whoever wants it.
config IOMMU_API
bool
+ select IOASID
menuconfig IOMMU_SUPPORT
bool "IOMMU Hardware Support"
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
0b7c96d1425e..570b244897bb 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2082,3 +2082,92 @@ void iommu_detach_device_aux(struct iommu_domain
*domain, struct device *dev)
}
}
EXPORT_SYMBOL_GPL(iommu_detach_device_aux);
+
+/*
+ * APIs for PASID used by IOMMU and the device drivers which depend
+ * on IOMMU.
+ */
+struct iommu_pasid *iommu_pasid_init(struct bus_type *bus) {
I'm thinking about if using struct iommu_domain here is better
than struct bus_type. The major purpose is to pass iommu_ops
in it and route into iommu-sublayer. iommu_domain may be
better since some modules like vfio_iommu_type1 would use
iommu_domain more than bus type.
But drivers might call this during initialization when it doesn't has
any domain yet.
Best regards,
Lu Baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Sunday, November 11, 2018 10:45 PM
> Subject: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
>
> This adds APIs for IOMMU drivers and device drivers to manage the PASIDs used
> for
> DMA transfer and translation. It bases on I/O ASID allocator for PASID
> namespace
> management and relies on vendor specific IOMMU drivers for paravirtual PASIDs.
>
> Below APIs are added:
>
> * iommu_pasid_init(pasid)
> - Initialize a PASID consumer. The vendor specific IOMMU
> drivers are able to set the PASID range imposed by IOMMU
> hardware through a callback in iommu_ops.
>
> * iommu_pasid_exit(pasid)
> - The PASID consumer stops consuming any PASID.
>
> * iommu_pasid_alloc(pasid, min, max, private, *ioasid)
> - Allocate a PASID and associate a @private data with this
> PASID. The PASID value is stored in @ioaisd if returning
> success.
>
> * iommu_pasid_free(pasid, ioasid)
> - Free a PASID to the pool so that it could be consumed by
> others.
>
> This also adds below helpers to lookup or iterate PASID items associated with
> a
> consumer.
>
> * iommu_pasid_for_each(pasid, func, data)
> - Iterate PASID items of the consumer identified by @pasid,
> and call @func() against each item. An error returned from
> @func() will break the iteration.
>
> * iommu_pasid_find(pasid, ioasid)
> - Retrieve the private data associated with @ioasid.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Kevin Tian
> Cc: Jean-Philippe Brucker
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/Kconfig | 1 +
> drivers/iommu/iommu.c | 89 +++
> include/linux/iommu.h | 73 +++
> 3 files changed, 163 insertions(+)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index
> d9a25715650e..39f2bb76c7b8 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -1,6 +1,7 @@
> # IOMMU_API always gets selected by whoever wants it.
> config IOMMU_API
> bool
> + select IOASID
>
> menuconfig IOMMU_SUPPORT
> bool "IOMMU Hardware Support"
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
> 0b7c96d1425e..570b244897bb 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2082,3 +2082,92 @@ void iommu_detach_device_aux(struct iommu_domain
> *domain, struct device *dev)
> }
> }
> EXPORT_SYMBOL_GPL(iommu_detach_device_aux);
> +
> +/*
> + * APIs for PASID used by IOMMU and the device drivers which depend
> + * on IOMMU.
> + */
> +struct iommu_pasid *iommu_pasid_init(struct bus_type *bus) {
I'm thinking about if using struct iommu_domain here is better
than struct bus_type. The major purpose is to pass iommu_ops
in it and route into iommu-sublayer. iommu_domain may be
better since some modules like vfio_iommu_type1 would use
iommu_domain more than bus type.
Thanks,
Yi Liu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [15/15] dma-mapping: bypass indirect calls for dma-direct
Hi, On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote: > Avoid expensive indirect calls in the fast path DMA mapping > operations by directly calling the dma_direct_* ops if we are using > the directly mapped DMA operations. > This patch results in arm64 boot failures. Reverting the patch fixes the problem. Bisect results are attached. Per logs, the system fails to instantiate the root device. Examples from two logs: [ 22.843080] nvme nvme0: pci function :00:02.0 [ 22.853820] nvme :00:02.0: enabling device ( -> 0002) [ 22.884178] nvme nvme0: Removing after probe failure status: -12 [ 15.451963] xhci_hcd :00:02.0: xHCI Host Controller [ 15.453294] xhci_hcd :00:02.0: new USB bus registered, assigned bus number 1 [ 15.456042] xhci_hcd :00:02.0: can't setup: -12 [ 15.457003] xhci_hcd :00:02.0: USB bus 1 deregistered [ 15.458340] xhci_hcd :00:02.0: init :00:02.0 fail, -12 [ 15.458825] xhci_hcd: probe of :00:02.0 failed with error -12 Guenter --- # bad: [d14b746c6c1ca310f679ef13f661587454e2c588] Add linux-next specific files for 20181214 # good: [40e020c129cfc991e8ab4736d2665351ffd1468d] Linux 4.20-rc6 git bisect start 'HEAD' 'v4.20-rc6' # bad: [ddfdda7f7d1ebdca0851f30a814e76749f08be99] Merge remote-tracking branch 'spi-nor/spi-nor/next' git bisect bad ddfdda7f7d1ebdca0851f30a814e76749f08be99 # bad: [466d2f8b964745cc8db7f126607e19526385f2d5] Merge remote-tracking branch 'file-locks/locks-next' git bisect bad 466d2f8b964745cc8db7f126607e19526385f2d5 # bad: [c43abf670f074a3eba2eebf9568ba95b2fe57f00] Merge remote-tracking branch 'arm-soc/for-next' git bisect bad c43abf670f074a3eba2eebf9568ba95b2fe57f00 # good: [e4337d9d50eb940a25d3808ef76bb0eaa61a0146] Merge branch 'next/dt' into for-next git bisect good e4337d9d50eb940a25d3808ef76bb0eaa61a0146 # bad: [32d851d8e81b1152d3e663b6c0b318474d649098] Merge remote-tracking branch 'dma-mapping/for-next' git bisect bad 32d851d8e81b1152d3e663b6c0b318474d649098 # good: [32550839013d8e72d35c1cc0a756c818d7f9ae32] Merge remote-tracking branch 'scsi-fixes/fixes' git bisect good 32550839013d8e72d35c1cc0a756c818d7f9ae32 # good: [8ea3ac17b6557f30697c624d1cd4ff2b30af82e1] Merge remote-tracking branch 'kbuild/for-next' git bisect good 8ea3ac17b6557f30697c624d1cd4ff2b30af82e1 # good: [ad78dee0b630527bdfed809d1f5ed95c601886ae] dma-debug: Batch dma_debug_entry allocation git bisect good ad78dee0b630527bdfed809d1f5ed95c601886ae # good: [55897af63091ebc2c3f239c6af748113ac50] dma-direct: merge swiotlb_dma_ops into the dma_direct code git bisect good 55897af63091ebc2c3f239c6af748113ac50 # good: [7d32be2e5abb2d88cf321357178d05c461b1cc83] leaking_addresses: do not parse binary files git bisect good 7d32be2e5abb2d88cf321357178d05c461b1cc83 # good: [9db33987ee2e5abb32a40dca44a2953391786833] leaking_addresses: remove version number git bisect good 9db33987ee2e5abb32a40dca44a2953391786833 # good: [7fd0d1346c1f96371a9a4996a590b86d570098f9] Merge remote-tracking branch 'leaks/leaks-next' git bisect good 7fd0d1346c1f96371a9a4996a590b86d570098f9 # bad: [356da6d0cde3323236977fce54c1f9612a742036] dma-mapping: bypass indirect calls for dma-direct git bisect bad 356da6d0cde3323236977fce54c1f9612a742036 # good: [190d4e5916a2d70a11009022b968fca948fb5dc7] vmd: use the proper dma_* APIs instead of direct methods calls git bisect good 190d4e5916a2d70a11009022b968fca948fb5dc7 # first bad commit: [356da6d0cde3323236977fce54c1f9612a742036] dma-mapping: bypass indirect calls for dma-direct ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection
On 12/15/18 2:47 AM, Christoph Hellwig wrote: On Fri, Dec 14, 2018 at 10:30:18PM -0800, Guenter Roeck wrote: and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem. Hi Guenter, can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs? sparc32 defconfig+CONFIG_SQUASHFS=y+CONFIG_DEVTMPFS=y, and: qemu-system-sparc -M SPARCClassic -kernel arch/sparc/boot/image \ -no-reboot -snapshot -drive file=/var/cache/buildbot/sparc/hda.sqf,if=scsi,format=raw \ -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 console=ttyS0' \ -nographic qemu version doesn't seem to matter. I used gcc-7.3.0 using the toolchain from kernel.org to build the image. Root file system is at https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc/. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: iommu: ipmmu-vmsa: Add r8a774c0 support
On Thu, Dec 13, 2018 at 08:19:28PM +, Fabrizio Castro wrote: > Document RZ/G2E (R8A774C0) SoC bindings. > > Signed-off-by: Fabrizio Castro Reviewed-by: Simon Horman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] kernel/dma/direct: Do not include SME mask in the DMA supported check
The mail seems to be so oddly encoded so that git-am fails on it. Can you resend as plain text? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection
On Fri, Dec 14, 2018 at 10:30:18PM -0800, Guenter Roeck wrote: > and so on, until qemu is terminated. This is seen with all sparc32 > qemu emulations. Reverting the patch fixes the problem. Hi Guenter, can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
