Re: [PATCH] iommu: Drop the of_iommu_{set/get}_ops() interface

On Wed, 2017-01-04 at 15:11 +, Robin Murphy wrote: > [+Yong Wu for mtk_iommu] > > On 03/01/17 17:34, Lorenzo Pieralisi wrote: > > With the introduction of the new iommu_{register/get}_instance() > > interface in commit e4f10ffe4c9b ("iommu: Make of_iommu_set/get_ops() DT > > agnostic") (based

RE: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

Hi Mark, > -Original Message- > From: Auger Eric [mailto:eric.au...@redhat.com] > Sent: Thursday, January 05, 2017 5:39 PM > To: Marc Zyngier ; eric.auger@gmail.com; > christoffer.d...@linaro.org; robin.mur...@arm.com; > alex.william...@redhat.com;

RE: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table()

Hi, Rafael > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table() > > From: Rafael J. Wysocki > > Linus reported that commit

[PATCH v6 14/18] irqdomain: irq_domain_check_msi_remap

This new function checks whether all MSI irq domains implement IRQ remapping. This is useful to understand whether VFIO passthrough is safe with respect to interrupts. On ARM typically an MSI controller can sit downstream to the IOMMU without preventing VFIO passthrough. As such any assigned

[PATCH v6 12/18] irqdomain: Add irq domain MSI and MSI_REMAP flags

We introduce two new enum values for the irq domain flag: - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to an MSI domain - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI remapping capabilities. Those values will be useful to check all MSI irq domains have MSI

[PATCH v6 18/18] iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP anymore

IOMMU_CAP_INTR_REMAP has been advertised in arm-smmu(-v3) although on ARM this property is not attached to the IOMMU but rather is implemented in the MSI controller (GICv3 ITS). Now vfio_iommu_type1 checks MSI remapping capability at MSI controller level, let's correct this. Signed-off-by: Eric

[PATCH v6 13/18] genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation

Now we have a flag value indicating an IRQ domain implements MSI, let's set it on msi_create_irq_domain(). Signed-off-by: Eric Auger --- v6: new --- kernel/irq/msi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/irq/msi.c

[PATCH v6 09/18] iommu/amd: Declare MSI and HT regions as reserved IOVA regions

This patch registers the MSI and HT regions as non mappable reserved regions. They will be exposed in the iommu-group sysfs. For direct-mapped regions let's also use iommu_alloc_resv_region(). Signed-off-by: Eric Auger --- v5: creation --- drivers/iommu/amd_iommu.c |

[PATCH v6 10/18] iommu/arm-smmu: Implement reserved region get/put callbacks

The get() populates the list with the MSI IOVA reserved window. At the moment an arbitray MSI IOVA window is set at 0x800 of size 1MB. This will allow to report those info in iommu-group sysfs. Signed-off-by: Eric Auger --- v3 -> v4: - do not handle PCI host bridge

[PATCH v6 06/18] iommu: iommu_get_group_resv_regions

Introduce iommu_get_group_resv_regions whose role consists in enumerating all devices from the group and collecting their reserved regions. The list is sorted and overlaps are checked. Signed-off-by: Eric Auger --- v3 -> v4: - take the iommu_group lock in

[PATCH v6 04/18] iommu: iommu_alloc_resv_region

Introduce a new helper serving the purpose to allocate a reserved region. This will be used in iommu driver implementing reserved region callbacks. Signed-off-by: Eric Auger --- v3 -> v4: - add INIT_LIST_HEAD(>list) - use int for prot param and add int type param -

[PATCH v6 08/18] iommu/vt-d: Implement reserved region get/put callbacks

This patch registers the [FEE0_h - FEF0_000h] 1MB MSI range as a reserved region. This will allow to report that range in the iommu-group sysfs. Signed-off-by: Eric Auger --- RFCv2 -> RFCv3: - use get/put_resv_region callbacks. RFC v1 -> RFC v2: - fix

[PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file

A new iommu-group sysfs attribute file is introduced. It contains the list of reserved regions for the iommu-group. Each reserved region is described on a separate line: - first field is the start IOVA address, - second is the end IOVA address, Signed-off-by: Eric Auger

[PATCH v6 03/18] iommu: Add a new type field in iommu_resv_region

We introduce a new field to differentiate the reserved region types and specialize the apply_resv_region implementation. Legacy direct mapped regions have IOMMU_RESV_DIRECT type. We introduce 2 new reserved memory types: - IOMMU_RESV_MSI will characterize MSI regions - IOMMU_RESV_NOMAP

[PATCH v6 02/18] iommu: Rename iommu_dm_regions into iommu_resv_regions

We want to extend the callbacks used for dm regions and use them for reserved regions. Reserved regions can be - directly mapped regions - regions that cannot be iommu mapped (PCI host bridge windows, ...) - MSI regions (because they belong to another address space or because they are not

[PATCH v6 01/18] iommu/dma: Allow MSI-only cookies

IOMMU domain users such as VFIO face a similar problem to DMA API ops with regard to mapping MSI messages in systems where the MSI write is subject to IOMMU translation. With the relevant infrastructure now in place for managed DMA domains, it's actually really simple for other users to piggyback

[PATCH v6 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions

Following LPC discussions, we now report reserved regions through iommu-group sysfs reserved_regions attribute file. Reserved regions are populated through the IOMMU get_resv_region callback (former get_dm_regions), now implemented by amd-iommu, intel-iommu and arm-smmu: - the intel-iommu reports

[PATCH v6 05/18] iommu: Only map direct mapped regions

As we introduced new reserved region types which do not require mapping, let's make sure we only map direct mapped regions. Signed-off-by: Eric Auger --- v3 -> v4: - use region's type and reword commit message and title --- drivers/iommu/iommu.c | 3 +++ 1 file changed,

Re: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table()

On Thu, Jan 5, 2017 at 2:24 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Linus reported that commit 174cc7187e6f "ACPICA: Tables: Back port > acpi_get_table_with_size() and early_acpi_os_unmap_memory() from > Linux kernel" added a new

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 05, 2017 at 05:03:30PM +, Robin Murphy wrote: > On 05/01/17 16:07, Will Deacon wrote: > > On Thu, Jan 05, 2017 at 03:32:50PM +, Robin Murphy wrote: > >> I think this needs to be some kind of "arm,smmu-stall-safe" property > >> placed on individual master device nodes (mad idea:

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On 05/01/17 16:07, Will Deacon wrote: > On Thu, Jan 05, 2017 at 03:32:50PM +, Robin Murphy wrote: >> On 05/01/17 14:47, Will Deacon wrote: >>> On Thu, Jan 05, 2017 at 02:07:31PM +, Mark Rutland wrote: Ok. It would be good to elaborate on what "stalling is useable" means in the

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 05, 2017 at 03:32:50PM +, Robin Murphy wrote: > On 05/01/17 14:47, Will Deacon wrote: > > On Thu, Jan 05, 2017 at 02:07:31PM +, Mark Rutland wrote: > >> Ok. It would be good to elaborate on what "stalling is useable" means in > >> the property description. i.e. what

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote: > On Thu, Jan 5, 2017 at 6:55 AM, Will Deacon wrote: > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote: > >> TODO maybe we want two options, one to enable stalling, and 2nd to punt > >> handling to wq? I

Re: [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration

On Thu, Jan 05, 2017 at 01:52:29PM +, Robin Murphy wrote: [...] > > Question: I had a look into this and instead of fiddling about with the > > linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this > > patchset would help remove entirely), I think that the only check we > >

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On 05/01/17 14:47, Will Deacon wrote: > On Thu, Jan 05, 2017 at 02:07:31PM +, Mark Rutland wrote: >> On Thu, Jan 05, 2017 at 02:00:05PM +, Will Deacon wrote: >>> On Thu, Jan 05, 2017 at 12:08:57PM +, Mark Rutland wrote: On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote:

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 5, 2017 at 6:55 AM, Will Deacon wrote: > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote: >> TODO maybe we want two options, one to enable stalling, and 2nd to punt >> handling to wq? I haven't needed to use mm APIs from fault handler yet >> (although

RE: [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration

Hi, [...] >>> >>> With the thinking of taking this series through, would it be fine if i >>> cleanup the pci configure hanging outside and push it in to >>> of/acpi_iommu configure respectively ? This time with all neeeded for >>> ACPI added as well. Also on the last post of V4, Lorenzo

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 05, 2017 at 02:07:31PM +, Mark Rutland wrote: > On Thu, Jan 05, 2017 at 02:00:05PM +, Will Deacon wrote: > > On Thu, Jan 05, 2017 at 12:08:57PM +, Mark Rutland wrote: > > > On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote: > > > > On Tue, Jan 03, 2017 at

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 05, 2017 at 02:00:05PM +, Will Deacon wrote: > On Thu, Jan 05, 2017 at 12:08:57PM +, Mark Rutland wrote: > > On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote: > > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote: > > > > diff --git

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Thu, Jan 05, 2017 at 12:08:57PM +, Mark Rutland wrote: > On Thu, Jan 05, 2017 at 11:55:29AM +, Will Deacon wrote: > > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote: > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > >

Re: [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration

On 05/01/17 12:27, Lorenzo Pieralisi wrote: > On Thu, Jan 05, 2017 at 02:04:37PM +0530, Sricharan wrote: >> Hi Robin/Lorenzo, >> >>> Hi Robin,Lorenzo, >>> On Wed, Nov 30, 2016 at 04:42:27PM +, Robin Murphy wrote: > On 30/11/16 16:17, Lorenzo Pieralisi wrote: >> Sricharan, Robin,

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

Hi Marc, On 05/01/2017 12:57, Marc Zyngier wrote: > On 05/01/17 11:29, Auger Eric wrote: >> Hi Marc, >> >> On 05/01/2017 12:25, Marc Zyngier wrote: >>> On 05/01/17 10:45, Auger Eric wrote: Hi Marc, On 04/01/2017 16:27, Marc Zyngier wrote: > On 04/01/17 14:11, Auger Eric wrote:

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 05/01/17 11:29, Auger Eric wrote: > Hi Marc, > > On 05/01/2017 12:25, Marc Zyngier wrote: >> On 05/01/17 10:45, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 16:27, Marc Zyngier wrote: On 04/01/17 14:11, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 14:46, Marc Zyngier

Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling

On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote: > TODO maybe we want two options, one to enable stalling, and 2nd to punt > handling to wq? I haven't needed to use mm APIs from fault handler yet > (although it is something that I think we'll want some day). Perhaps > stalling support

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

Hi Marc, On 05/01/2017 12:25, Marc Zyngier wrote: > On 05/01/17 10:45, Auger Eric wrote: >> Hi Marc, >> >> On 04/01/2017 16:27, Marc Zyngier wrote: >>> On 04/01/17 14:11, Auger Eric wrote: Hi Marc, On 04/01/2017 14:46, Marc Zyngier wrote: > Hi Eric, > > On 04/01/17

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 05/01/17 10:45, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 16:27, Marc Zyngier wrote: >> On 04/01/17 14:11, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 14:46, Marc Zyngier wrote: Hi Eric, On 04/01/17 13:32, Eric Auger wrote: > This new function checks whether

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

Hi Marc, On 04/01/2017 16:27, Marc Zyngier wrote: > On 04/01/17 14:11, Auger Eric wrote: >> Hi Marc, >> >> On 04/01/2017 14:46, Marc Zyngier wrote: >>> Hi Eric, >>> >>> On 04/01/17 13:32, Eric Auger wrote: This new function checks whether all platform and PCI MSI domains implement IRQ

Re: [PATCH] ACPI / DMAR: Avoid passing NULL to acpi_put_table()

On Thu, Jan 05, 2017 at 01:24:14AM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Linus reported that commit 174cc7187e6f "ACPICA: Tables: Back port > acpi_get_table_with_size() and early_acpi_os_unmap_memory() from > Linux kernel" added a new warning

RE: [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration

Hi Robin/Lorenzo, >Hi Robin,Lorenzo, > >>On Wed, Nov 30, 2016 at 04:42:27PM +, Robin Murphy wrote: >>> On 30/11/16 16:17, Lorenzo Pieralisi wrote: >>> > Sricharan, Robin, >>> > >>> > I gave this series a go on ACPI and apart from an SMMU v3 fix-up >>> > it seems to work, more thorough testing