Re: DPAA2 triggers, [PATCH] dma debug: report -EEXIST errors in add_dma_entry

2021-10-07 Thread Gerald Schaefer
On Thu, 7 Oct 2021 12:59:32 +0200 Karsten Graul wrote: [...] > > > >>> BTW, there is already a WARN in the add_dma_entry() path, related > >>> to cachlline overlap and -EEXIST: > >>> > >>> add_dma_entry() -> active_cacheline_insert() -> -EEXIST -> > >>> active_cacheline_inc_overlap() > >>> > >>>

[PATCH] dma-debug: fix sg checks in debug_dma_map_sg()

2021-10-06 Thread Gerald Schaefer
dividual sg elements. Link: https://lore.kernel.org/lkml/20210705185252.4074653-1-gerald.schae...@linux.ibm.com Fixes: 884d05970bfb ("dma-debug: use sg_dma_len accessor") Signed-off-by: Gerald Schaefer --- kernel/dma/debug.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-)

Re: DPAA2 triggers, [PATCH] dma debug: report -EEXIST errors in add_dma_entry

2021-10-06 Thread Gerald Schaefer
On Wed, 6 Oct 2021 15:23:36 +0100 Robin Murphy wrote: > On 2021-10-06 14:10, Gerald Schaefer wrote: > > On Fri, 1 Oct 2021 14:52:56 +0200 > > Gerald Schaefer wrote: > > > >> On Thu, 30 Sep 2021 15:37:33 +0200 > >> Karsten Graul wrote: > >>

Re: DPAA2 triggers, [PATCH] dma debug: report -EEXIST errors in add_dma_entry

2021-10-06 Thread Gerald Schaefer
On Wed, 6 Oct 2021 15:10:43 +0200 Gerald Schaefer wrote: > On Fri, 1 Oct 2021 14:52:56 +0200 > Gerald Schaefer wrote: > > > On Thu, 30 Sep 2021 15:37:33 +0200 > > Karsten Graul wrote: > > > > > On 14/09/2021 17:45, Ioana Ciornei wrote: > > > >

Re: DPAA2 triggers, [PATCH] dma debug: report -EEXIST errors in add_dma_entry

2021-10-06 Thread Gerald Schaefer
On Fri, 1 Oct 2021 14:52:56 +0200 Gerald Schaefer wrote: > On Thu, 30 Sep 2021 15:37:33 +0200 > Karsten Graul wrote: > > > On 14/09/2021 17:45, Ioana Ciornei wrote: > > > On Wed, Sep 08, 2021 at 10:33:26PM -0500, Jeremy Linton wrote: > > >>

Re: DPAA2 triggers, [PATCH] dma debug: report -EEXIST errors in add_dma_entry

2021-10-01 Thread Gerald Schaefer
On Thu, 30 Sep 2021 15:37:33 +0200 Karsten Graul wrote: > On 14/09/2021 17:45, Ioana Ciornei wrote: > > On Wed, Sep 08, 2021 at 10:33:26PM -0500, Jeremy Linton wrote: > >> +DPAA2, netdev maintainers > >> Hi, > >> > >> On 5/18/21 7:54 AM, Hamza Mahfooz wrote: > >>> Since, overlapping mappings are

Re: [RFC PATCH 1/1] dma-debug: fix check_for_illegal_area() in debug_dma_map_sg()

2021-07-06 Thread Gerald Schaefer
On Tue, 6 Jul 2021 10:22:40 +0100 Robin Murphy wrote: > On 2021-07-05 19:52, Gerald Schaefer wrote: > > The following warning occurred sporadically on s390: > > DMA-API: nvme 0006:00:00.0: device driver maps memory from kernel text or > > rodata [addr=48cc5e2f] [le

[RFC PATCH 1/1] dma-debug: fix check_for_illegal_area() in debug_dma_map_sg()

2021-07-05 Thread Gerald Schaefer
en(s). Also put the call to check_for_illegal_area() in a separate loop, iterating over all the individual sg elements ("nents" instead of "mapped_ents"). Fixes: 884d05970bfb ("dma-debug: use sg_dma_len accessor") Tested-by: Niklas Schnelle Signed-off-by:

[RFC PATCH 0/1] dma-debug: fix check_for_illegal_area() in debug_dma_map_sg()

2021-07-05 Thread Gerald Schaefer
t iterates over mapped_ents instead of nents. So it would not check all physical sg elements if any were combined in DMA address space. Gerald Schaefer (1): dma-debug: fix check_for_illegal_area() in debug_dma_map_sg() kernel/dma/debug.c | 10 ++ 1 file changed, 6 insertions(+), 4

[PATCH] iommu/intel-iommu: fix memory leak in intel_iommu_put_resv_regions()

2019-01-16 Thread Gerald Schaefer
isambiguate MSI region types") Cc: # v4.11+ Signed-off-by: Gerald Schaefer --- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 048b5ab36a02..b83e0f2025bb 100644 --- a/drivers/iommu

Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions

2019-01-15 Thread Gerald Schaefer
_iommu_remove_device, > .device_group = generic_device_group, > .pgsize_bitmap = S390_IOMMU_PGSIZES, > + .get_resv_regions = s390_get_resv_regions, > + .put_resv_regions = s390_put_resv_regions, > }; > > static int __init s390_iommu_init(void) With the start/end_dma issue addressed (if necessary): Acked-by: Gerald Schaefer ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/3] iommu: s390: constify iommu_ops

2017-08-28 Thread Gerald Schaefer
drivers/iommu/s390-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Gerald Schaefer > > diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c > index 8788640..400d75f 100644 > --- a/drivers/iommu/s390-iommu.c > +++ b/drivers/iommu

Re: [PATCH 2/2] iommu/s390: Add support for iommu_device handling

2017-06-29 Thread Gerald Schaefer
On Tue, 27 Jun 2017 17:28:06 +0200 Joerg Roedel wrote: > On Mon, Jun 19, 2017 at 05:02:19PM +0200, Gerald Schaefer wrote: > > On Thu, 15 Jun 2017 15:11:52 +0200 > > Joerg Roedel wrote: > > > + rc = zpci_init_iommu(zdev); > > > + if (rc) > > > +

Re: [PATCH 1/3] iommu: Return ERR_PTR() values from device_group call-backs

2017-06-28 Thread Gerald Schaefer
On Wed, 28 Jun 2017 14:00:56 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > The generic device_group call-backs in iommu.c return NULL > in case of error. Since they are getting ERR_PTR values from > iommu_group_alloc(), just pass them up instead. > > Reporte

Re: [PATCH 2/2] iommu/s390: Add support for iommu_device handling

2017-06-19 Thread Gerald Schaefer
On Thu, 15 Jun 2017 15:11:52 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > Add support for the iommu_device_register interface to make > the s390 hardware iommus visible to the iommu core and in > sysfs. > > Signed-off-by: Joerg Roedel > --- > arch/s390/include/asm/pci.h | 7 +++ >

Re: [PATCH 1/2] iommu/s390: Use iommu_group_get_for_dev() in s390_iommu_add_device()

2017-06-16 Thread Gerald Schaefer
can make use of > default domains in the future. > > Signed-off-by: Joerg Roedel Seems pretty straightforward, so Reviewed-by: Gerald Schaefer However, looking at iommu_group_get_for_dev(), I wonder if the generic_device_group() always returns the right thing, but that would be

Re: [PATCH 19/44] s390: implement ->mapping_error

2017-06-08 Thread Gerald Schaefer
f-by: Christoph Hellwig Acked-by: Gerald Schaefer ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

2017-04-28 Thread Gerald Schaefer
On Fri, 28 Apr 2017 16:55:13 +0200 Joerg Roedel wrote: > > I am however a bit confused now, about how we would have allowed group > > sharing with the current s390 IOMMU code, or IOW in which scenario would > > iommu_group_get() in the add_device callback find a shareable iommu-group? > > The

Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups

2017-04-28 Thread Gerald Schaefer
On Thu, 27 Apr 2017 23:12:32 +0200 Joerg Roedel wrote: > On Thu, Apr 27, 2017 at 08:11:42PM +0200, Gerald Schaefer wrote: > > > +void zpci_destroy_iommu(struct zpci_dev *zdev) > > > +{ > > > + iommu_group_put(zdev->group); > > > + zdev->group = NUL

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

2017-04-28 Thread Gerald Schaefer
Hi Joerg, I guess we are a bit special on s390 (again), see below. Sebastian is more familiar with the base s390 PCI code, he may correct me if I'm wrong. On Thu, 27 Apr 2017 23:03:25 +0200 Joerg Roedel wrote: > > Well, there is a separate zpci_dev for each pci_dev on s390, > > and each of thos

Re: [PATCH 1/2] iommu/s390: Fix IOMMU groups

2017-04-27 Thread Gerald Schaefer
On Thu, 27 Apr 2017 17:28:24 +0200 Joerg Roedel wrote: > From: Joerg Roedel > > Currently the s390 iommu driver allocates an iommu-group for > every device that is added. But that is wrong, as there is > only one dma-table per pci-root-bus. Make all devices behind > one dma-table share one iomm

Re: [RFC PATCH 0/2] iommu/s390: Fix iommu-groups and add sysfs support

2017-04-27 Thread Gerald Schaefer
On Thu, 27 Apr 2017 17:28:23 +0200 Joerg Roedel wrote: > Hey, > > here are two patches for the s390 PCI and IOMMU code. It is > based on the assumption that every pci_dev that points to > the same zpci_dev shares a single dma-table (and thus a > single address space). Well, there is a separate

Re: [PATCH] iommu/s390: add iommu api for s390 pci devices

2015-10-01 Thread Gerald Schaefer
device recovery and map/unmap on s390. > > My other question is inline: > > On Thu, Aug 27, 2015 at 03:33:03PM +0200, Gerald Schaefer wrote: > > +struct s390_domain_device { > > + struct list_headlist; > > + struct zpci_dev *zdev; > > +}; >

[PATCH] iommu/s390: add iommu api for s390 pci devices

2015-08-27 Thread Gerald Schaefer
This adds an IOMMU API implementation for s390 PCI devices. Reviewed-by: Sebastian Ott Signed-off-by: Gerald Schaefer --- MAINTAINERS | 7 + arch/s390/Kconfig | 1 + arch/s390/include/asm/pci.h | 4 + arch/s390/include/asm/pci_dma.h | 5 +- arch

Re: [RFC PATCH 0/1] iommu: Detach device from domain when removed from group

2015-08-03 Thread Gerald Schaefer
On Mon, 3 Aug 2015 17:48:55 +0200 Joerg Roedel wrote: > On Tue, Jul 28, 2015 at 07:55:55PM +0200, Gerald Schaefer wrote: > > On s390, this eventually leads to a kernel panic when binding the device > > again to its non-vfio PCI driver, because of the missing arch-specific

Re: [RFC PATCH 0/1] iommu: Detach device from domain when removed from group

2015-08-03 Thread Gerald Schaefer
On Tue, 28 Jul 2015 19:55:55 +0200 Gerald Schaefer wrote: > Hi, > > during IOMMU API function testing on s390 I hit the following scenario: > > After binding a device to vfio-pci, the user completes the VFIO_SET_IOMMU > ioctl and stops, see the sample C program below.

[RFC PATCH 1/1] iommu: Detach device from domain when removed from group

2015-07-28 Thread Gerald Schaefer
quot;detach_dev". Signed-off-by: Gerald Schaefer --- drivers/iommu/iommu.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index f286090..82ac8b3 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -447,6 +447,9 @@ rename:

[RFC PATCH 0/1] iommu: Detach device from domain when removed from group

2015-07-28 Thread Gerald Schaefer
} rc = ioctl(container, VFIO_SET_IOMMU, VFIO_TYPE1_IOMMU); if (rc) { perror("ioctl VFIO_SET_IOMMU\n"); return -1; } printf("Try device remove...\n"); getchar(); close(group); close(container); retur

Re: [RFC PATCH 1/1] vfio-pci/iommu: Detach iommu group on remove path

2015-07-23 Thread Gerald Schaefer
On Wed, 22 Jul 2015 11:10:57 -0600 Alex Williamson wrote: > On Wed, 2015-07-22 at 10:54 -0600, Alex Williamson wrote: > > On Tue, 2015-07-21 at 19:44 +0200, Gerald Schaefer wrote: > > > When a user completes the VFIO_SET_IOMMU ioctl and the vfio-pci > > > device is rem

Re: [RFC PATCH 1/1] vfio-pci/iommu: Detach iommu group on remove path

2015-07-23 Thread Gerald Schaefer
On Wed, 22 Jul 2015 10:54:35 -0600 Alex Williamson wrote: > On Tue, 2015-07-21 at 19:44 +0200, Gerald Schaefer wrote: > > When a user completes the VFIO_SET_IOMMU ioctl and the vfio-pci > > device is removed thereafter (before any other ioctl like > > VFIO_GROUP_GET

Re: [PATCH linux-next] iommu: add iommu for s390 platform

2014-10-27 Thread Gerald Schaefer
On Mon, 27 Oct 2014 18:58:35 +0100 Joerg Roedel wrote: > On Mon, Oct 27, 2014 at 06:02:19PM +0100, Gerald Schaefer wrote: > > On Mon, 27 Oct 2014 17:25:02 +0100 > > Joerg Roedel wrote: > > > Is there some hardware reason for this or is that just an > > >

Re: [PATCH linux-next] iommu: add iommu for s390 platform

2014-10-27 Thread Gerald Schaefer
On Mon, 27 Oct 2014 17:25:02 +0100 Joerg Roedel wrote: > On Mon, Oct 27, 2014 at 03:32:01PM +0100, Gerald Schaefer wrote: > > Not sure if I understood the concept of IOMMU domains right. But if > > this is about having multiple devices in the same domain, so that > >

Re: [PATCH linux-next] iommu: add iommu for s390 platform

2014-10-27 Thread Gerald Schaefer
On Thu, 23 Oct 2014 16:04:37 +0200 Frank Blaschka wrote: > On Thu, Oct 23, 2014 at 02:41:15PM +0200, Joerg Roedel wrote: > > On Wed, Oct 22, 2014 at 05:43:20PM +0200, Frank Blaschka wrote: > > > Basically there are no limitations. Depending on the s390 maschine > > > generation a device starts it