Re: [PATCH v2 0/3] iommu/amd: I/O VA address limits

Hello Joerg, On 2020-07-10 14:31, Joerg Roedel wrote: On Wed, Jul 01, 2020 at 12:46:31AM +0200, Sebastian Ott wrote: The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses that can be handled by the IOMMUs in the system. Parse that data from the IVRS header to provide

[PATCH v2 0/3] iommu/amd: I/O VA address limits

() - rebased to current upstream Sebastian Ott (3): iommu/amd: Parse supported address sizes from IVRS iommu/amd: Restrict aperture for domains to conform with IVRS iommu/amd: Actually enforce geometry aperture drivers/iommu/amd/amd_iommu_types.h | 3 +++ drivers/iommu/amd/init.c

[PATCH v2 3/3] iommu/amd: Actually enforce geometry aperture

Add a check to enforce that I/O virtual addresses picked by iommu API users stay within the domains geometry aperture. Signed-off-by: Sebastian Ott Cc: Benjamin Serebrin Cc: Filippo Sironi CR: https://code.amazon.com/reviews/CR-26408388 --- drivers/iommu/amd/iommu.c | 9 - 1 file

[PATCH v2 1/3] iommu/amd: Parse supported address sizes from IVRS

: https://www.amd.com/system/files/TechDocs/48882_IOMMU_3.05_PUB.pdf Signed-off-by: Sebastian Ott Cc: Benjamin Serebrin Cc: Filippo Sironi CR: https://code.amazon.com/reviews/CR-26408321 --- drivers/iommu/amd/amd_iommu_types.h | 3 +++ drivers/iommu/amd/init.c| 26

[PATCH v2 2/3] iommu/amd: Restrict aperture for domains to conform with IVRS

The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses. When allocating new protection domains that perform translation, propagate these limits as the domain's geometry / aperture. Based on prior work by Marius Hillenbrand. Signed-off-by: Sebastian Ott Cc: Benjamin

Re: [PATCH 0/3] iommu/amd: I/O VA address limits

Hello Joerg, On 2020-06-05 16:56, Sebastian Ott wrote: The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses that can be handled by the IOMMUs in the system. Parse that data from the IVRS header to provide aperture information for DMA mappings and users of the iommu API

[PATCH 3/3] iommu/amd: Actually enforce geometry aperture

Add a check to enforce that I/O virtual addresses picked by iommu API users stay within the domains geometry aperture. Signed-off-by: Sebastian Ott --- drivers/iommu/amd_iommu.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index

[PATCH 2/3] iommu/amd: Restrict aperture for domains to conform with IVRS

The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses. When allocating new protection domains that perform translation, propagate these limits as the domain's geometry / aperture. Based on prior work by Marius Hillenbrand. Signed-off-by: Sebastian Ott --- drivers/iommu

[PATCH 1/3] iommu/amd: Parse supported address sizes from IVRS

/system/files/TechDocs/48882_IOMMU_3.05_PUB.pdf Signed-off-by: Sebastian Ott --- drivers/iommu/amd_iommu.c | 1 + drivers/iommu/amd_iommu_init.c | 26 ++ drivers/iommu/amd_iommu_types.h | 3 +++ 3 files changed, 30 insertions(+) diff --git a/drivers/iommu/amd_iommu.c

[PATCH 0/3] iommu/amd: I/O VA address limits

The IVRS ACPI table specifies maximum address sizes for I/O virtual addresses that can be handled by the IOMMUs in the system. Parse that data from the IVRS header to provide aperture information for DMA mappings and users of the iommu API. Sebastian Ott (3): iommu/amd: Parse supported address

Re: [PATCH v8 3/7] s390/pci: add support for IOMMU default DMA mode build options

On Thu, 30 May 2019, Zhen Lei wrote: > The default DMA mode is LAZY on s390, this patch make it can be set to > STRICT at build time. It can be overridden by boot option. > > There is no functional change. > > Signed-off-by: Zhen Lei Acked

Re: [PATCH v5 4/6] s390/pci: add support for generic boot option iommu.dma_mode

On Tue, 9 Apr 2019, Zhen Lei wrote: > s390_iommu=strict is equivalent to iommu.dma_mode=strict. > > Signed-off-by: Zhen Lei Acked-by: Sebastian Ott ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.or

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

On Tue, 15 Aug 2017, Joerg Roedel wrote: > On Tue, Aug 15, 2017 at 06:02:20PM +0200, Sebastian Ott wrote: > > On Mon, 14 Aug 2017, Joerg Roedel wrote: > > > I attach the patch I wrote to fix this, can you please test it together > > > with the initial patch in this thr

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

On Mon, 14 Aug 2017, Joerg Roedel wrote: > I attach the patch I wrote to fix this, can you please test it together > with the initial patch in this thread? I did and can confirm that everything worked as expected! Thanks, Sebastian ___ iommu mailing

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

On Fri, 11 Aug 2017, Sebastian Ott wrote: > * That patch embedded a struct iommu_device within struct zpci_dev but > the iommu_device has a release function (via its class) - so when > the release function gets called it frees memory that was never allocated. > The fix is to not e

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

On Fri, 11 Aug 2017, Sebastian Ott wrote: > * iommu_release_device must not release the struct device but the > structure it is embedded in: struct iommu_device (I'll send a patch > for that) --->8 >From 2839c92e038af47b8cb569f84d571878c54d1815 Mon Sep 17 00:00:00 2001 From: Seb

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

Hello Joerg, On Fri, 11 Aug 2017, Joerg Roedel wrote: > Hey Sebastian, > > On Thu, Aug 10, 2017 at 09:07:06PM +0200, Sebastian Ott wrote: > > With this patch pci hot-unplug fails with a use after free or refcounting > > issue - I'm currently trying to understand what's go

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

On Wed, 9 Aug 2017, 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. > With this patch pci hot-unplug fails with a use after free or refcounting issue -

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

On Fri, 28 Apr 2017, Joerg Roedel wrote: > On Fri, Apr 28, 2017 at 02:46:34PM +0200, Gerald Schaefer wrote: > > 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 those has its

[PATCH] iommu/s390: fix sparse warnings

-by: Sebastian Ott <seb...@linux.vnet.ibm.com> --- drivers/iommu/s390-iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c index cbe198c..030e94c 100644 --- a/drivers/iommu/s390-iommu.c +++ b/drivers/iommu/s390-iommu.c @@

Re: [PATCH v3 22/27] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq

On Wed, 15 Oct 2014, Yijing Wang wrote: Use MSI chip framework instead of arch MSI functions to configure MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. Signed-off-by: Yijing Wang wangyij...@huawei.com --- Hi Sebastian, I dropped the Acked-by , because this

Re: [PATCH v1 16/21] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq

than that: Acked-by: Sebastian Ott seb...@linux.vnet.ibm.com Regards, Sebastian irq_set_msi_desc(msi-irq, NULL); irq_free_desc(msi-irq); msi-msg.address_lo = 0; @@ -464,6 +464,16 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev