Re: [PATCH 01/11] dt-bindings: iommu: arm,smmu-v3: make PRI IRQ optional
On Thu, 28 Apr 2022 08:56:38 +0200 Krzysztof Kozlowski wrote: Hi, > On 27/04/2022 13:25, Andre Przywara wrote: > > The Page Request Interface (PRI) is an optional PCIe feature. As such, a > > SMMU would not need to handle it if the PCIe host bridge or the SMMU > > itself do not implement it. Also an SMMU could be connected to a platform > > device, without any PRI functionality whatsoever. > > In all cases there would be no SMMU PRI queue interrupt to be wired up > > to an interrupt controller. > > > > Relax the binding to allow specifying three interrupts, omitting the PRI > > IRQ. At the moment, with the "eventq,gerror,priq,cmdq-sync" order, we > > would need to sacrifice the command queue sync interrupt as well, which > > might not be desired. > > The Linux driver does not care about any order at all, just picks IRQs > > based on their names, and treats all (wired) IRQs as optional. > > The last sentence is not a good explanation for the bindings. They are > not about Linux and are used in other projects as well. It was not meant as an explanation, but just as an assurance that we can *change* the binding. At the moment the order is strict, so binding compliant DT consumers could just read the first, second, third, and fourth interrupt, without caring about the names. If we now allow a different order, this would break those users. I couldn't find any user of arm,smmu-v3 in FreeBSD, OpenBSD, U-Boot, or Zephyr, hence my mentioning of Linux being fine, so it's safe to relax the strict ordering requirement. If someone knows about other DT consumers that need attention, I am all ears. Cheers, Andre > > Signed-off-by: Andre Przywara > > --- > > .../bindings/iommu/arm,smmu-v3.yaml | 21 ++- > > 1 file changed, 16 insertions(+), 5 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > > b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > > index e87bfbcc69135..6b3111f1f06ce 100644 > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml > > @@ -37,12 +37,23 @@ properties: > >hardware supports just a single, combined interrupt line. > >If provided, then the combined interrupt will be used in > > preference to > >any others. > > - - minItems: 2 > > + - minItems: 1 > > items: > > - - const: eventq # Event Queue not empty > > - - const: gerror # Global Error activated > > - - const: priq # PRI Queue not empty > > - - const: cmdq-sync # CMD_SYNC complete > > + - enum: > > + - eventq # Event Queue not empty > > + - gerror # Global Error activated > > + - cmdq-sync # CMD_SYNC complete > > + - priq # PRI Queue not empty > > + - enum: > > + - gerror > > + - cmdq-sync > > + - priq > > + - enum: > > + - cmdq-sync > > + - priq > > + - enum: > > + - cmdq-sync > > + - priq > > The order should be strict, so if you want the first interrupt optional, > then: > oneOf: > - items: > ... 4 items list > - items > ... 3 items list > > Best regards, > Krzysztof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 01/11] dt-bindings: iommu: arm, smmu-v3: make PRI IRQ optional
The Page Request Interface (PRI) is an optional PCIe feature. As such, a SMMU would not need to handle it if the PCIe host bridge or the SMMU itself do not implement it. Also an SMMU could be connected to a platform device, without any PRI functionality whatsoever. In all cases there would be no SMMU PRI queue interrupt to be wired up to an interrupt controller. At the moment, with the "eventq,gerror,priq,cmdq-sync" order, we would need to sacrifice the command queue sync interrupt as well, which might not be desired. Relax the binding to allow specifying certain useful combinations of wired interrupts, for instance just the "gerror" interrupt, or omitting both "pri" and "cmdq-sync". Signed-off-by: Andre Przywara --- .../devicetree/bindings/iommu/arm,smmu-v3.yaml | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml index e87bfbcc69135..c57a53d87e4e6 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml @@ -37,12 +37,18 @@ properties: hardware supports just a single, combined interrupt line. If provided, then the combined interrupt will be used in preference to any others. - - minItems: 2 + - minItems: 1 items: - - const: eventq # Event Queue not empty - - const: gerror # Global Error activated - - const: priq # PRI Queue not empty - - const: cmdq-sync # CMD_SYNC complete + - enum: + - eventq # Event Queue not empty + - gerror # Global Error activated + - const: gerror + - enum: + - cmdq-sync # CMD_SYNC complete + - priq # PRI Queue not empty + - enum: + - cmdq-sync + - priq '#iommu-cells': const: 1 -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 01/11] dt-bindings: iommu: arm,smmu-v3: make PRI IRQ optional
The Page Request Interface (PRI) is an optional PCIe feature. As such, a SMMU would not need to handle it if the PCIe host bridge or the SMMU itself do not implement it. Also an SMMU could be connected to a platform device, without any PRI functionality whatsoever. In all cases there would be no SMMU PRI queue interrupt to be wired up to an interrupt controller. Relax the binding to allow specifying three interrupts, omitting the PRI IRQ. At the moment, with the "eventq,gerror,priq,cmdq-sync" order, we would need to sacrifice the command queue sync interrupt as well, which might not be desired. The Linux driver does not care about any order at all, just picks IRQs based on their names, and treats all (wired) IRQs as optional. Signed-off-by: Andre Przywara --- .../bindings/iommu/arm,smmu-v3.yaml | 21 ++- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml index e87bfbcc69135..6b3111f1f06ce 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml @@ -37,12 +37,23 @@ properties: hardware supports just a single, combined interrupt line. If provided, then the combined interrupt will be used in preference to any others. - - minItems: 2 + - minItems: 1 items: - - const: eventq # Event Queue not empty - - const: gerror # Global Error activated - - const: priq # PRI Queue not empty - - const: cmdq-sync # CMD_SYNC complete + - enum: + - eventq # Event Queue not empty + - gerror # Global Error activated + - cmdq-sync # CMD_SYNC complete + - priq # PRI Queue not empty + - enum: + - gerror + - cmdq-sync + - priq + - enum: + - cmdq-sync + - priq + - enum: + - cmdq-sync + - priq '#iommu-cells': const: 1 -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: fully convert arm to use dma-direct
On Thu, 21 Apr 2022 09:41:57 +0200 Christoph Hellwig wrote: Hi, > arm is the last platform not using the dma-direct code for directly > mapped DMA. With the dmaboune removal from Arnd we can easily switch > arm to always use dma-direct now (it already does for LPAE configs > and nommu). I'd love to merge this series through the dma-mapping tree > as it gives us the opportunity for additional core dma-mapping > improvements. > > Diffstat: > arch/arm/common/dmabounce.c | 582 > --- > arch/arm/include/asm/dma-mapping.h | 128 > b/arch/arm/Kconfig |5 > b/arch/arm/common/Kconfig|6 > b/arch/arm/common/Makefile |1 > b/arch/arm/common/sa.c | 64 -- > b/arch/arm/include/asm/device.h |3 > b/arch/arm/include/asm/dma-direct.h | 49 - > b/arch/arm/include/asm/memory.h |2 > b/arch/arm/mach-footbridge/Kconfig |1 > b/arch/arm/mach-footbridge/common.c | 19 > b/arch/arm/mach-footbridge/include/mach/dma-direct.h |8 > b/arch/arm/mach-footbridge/include/mach/memory.h |4 > b/arch/arm/mach-highbank/highbank.c |2 FWIW, I applied this on top of 5.18-rc3 and pushed my Midway (the Highbank successor) a bit with it (scp-ing GBs forth and back to a SATA SSD). Not a really conclusive test, but so far it looks all fine. So for the Highbank part: Acked-by: Andre Przywara Cheers, Andre > b/arch/arm/mach-mvebu/coherency.c|2 > b/arch/arm/mm/dma-mapping.c | 381 > b/drivers/usb/core/hcd.c | 17 > b/drivers/usb/host/ohci-sa.c | 25 > 18 files changed, 84 insertions(+), 1215 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/arm-smmu-v3: Add default domain quirk for Arm Fast Models
On Fri, 18 Jun 2021 17:24:49 +0100
Robin Murphy wrote:
Hi Robin,
> Arm Fast Models are still implementing legacy virtio-pci devices behind
> the SMMU, which continue to be problematic as "real hardware" devices
> (from the point of view of the simulated system) without the mitigating
> VIRTIO_F_ACCESS_PLATFORM feature.
>
> Since we now have the ability to force passthrough on a device-specific
> basis, let's use it to work around this particular oddity so that people
> who just want to boot Linux on a model don't have to fiddle around with
> things to avoid the SMMU getting in the way by default (and I don't have
> to keep telling them which things...)
>
> Signed-off-by: Robin Murphy
So it looks somewhat quirky, but it indeed fixes the boot problems on
the RevC model for me.
And given that currently an out-of-the-box kernel build fails booting
(with the kernel DT), I'd like to see that merged.
Tested-by: Andre Przywara
Thanks,
Andre
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 54b2f27b81d4..13cf16e8f45b 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -2649,6 +2649,20 @@ static int arm_smmu_dev_disable_feature(struct device
> *dev,
> }
> }
>
> +static int arm_smmu_def_domain_type(struct device *dev)
> +{
> + if (dev_is_pci(dev)) {
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + /* Legacy virtio-block devices on Arm Fast Models */
> + if (pdev->vendor == 0x1af4 && pdev->device == 0x1001 &&
> + pdev->subsystem_vendor == 0x00ff && pdev->subsystem_device
> == 0x0002)
> + return IOMMU_DOMAIN_IDENTITY;
> + }
> +
> + return 0;
> +}
> +
> static struct iommu_ops arm_smmu_ops = {
> .capable= arm_smmu_capable,
> .domain_alloc = arm_smmu_domain_alloc,
> @@ -2673,6 +2687,7 @@ static struct iommu_ops arm_smmu_ops = {
> .sva_bind = arm_smmu_sva_bind,
> .sva_unbind = arm_smmu_sva_unbind,
> .sva_get_pasid = arm_smmu_sva_get_pasid,
> + .def_domain_type= arm_smmu_def_domain_type,
> .pgsize_bitmap = -1UL, /* Restricted during device attach */
> .owner = THIS_MODULE,
> };
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 01/17] dt-bindings: arm-smmu: Allow mmu-400, smmu-v1 compatible
The Arm SMMUv1 DT binding only allows combining arm,mmu-401 with arm,smmu-v1, even though the MMU-400 is compatible as well. Allow this combination as well to let the Arm Juno board pass the test. Signed-off-by: Andre Przywara Acked-by: Robin Murphy --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 6515dbe47508..e3ef1c69d132 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -41,7 +41,9 @@ properties: - const: arm,mmu-500 - const: arm,smmu-v2 - items: - - const: arm,mmu-401 + - enum: + - arm,mmu-400 + - arm,mmu-401 - const: arm,smmu-v1 - enum: - arm,smmu-v1 -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 00/16] dts/dt-bindings: Fix Arm Ltd. ARMv8 "boards"
Date: Mon, 4 May 2020 12:42:49 +0100 Subject: [PATCH 02/16] dt-bindings: arm-smmu: Allow mmu-400,smmu-v1 compatible The Arm SMMUv1 DT binding only allows combining arm,mmu-401 with arm,smmu-v1, even though the MMU-400 is compatible as well. Allow this combination as well to let the Arm Juno board pass the test. Signed-off-by: Andre Przywara --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 6515dbe47508..e3ef1c69d132 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -41,7 +41,9 @@ properties: - const: arm,mmu-500 - const: arm,smmu-v2 - items: - - const: arm,mmu-401 + - enum: + - arm,mmu-400 + - arm,mmu-401 - const: arm,smmu-v1 - enum: - arm,smmu-v1 -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] vfio: Ignore -ENODEV when getting MSI cookie
When we try to get an MSI cookie for a VFIO device, that can fail if
CONFIG_IOMMU_DMA is not set. In this case iommu_get_msi_cookie() returns
-ENODEV, and that should not be fatal.
Ignore that case and proceed with the initialisation.
This fixes VFIO with a platform device on the Calxeda Midway (no MSIs).
Fixes: f6810c15cf973f ("iommu/arm-smmu: Clean up early-probing workarounds")
Signed-off-by: Andre Przywara
Acked-by: Robin Murphy
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_iommu_type1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 9fdfae1cb17a..85b32c325282 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1787,7 +1787,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
if (resv_msi) {
ret = iommu_get_msi_cookie(domain->domain, resv_msi_base);
- if (ret)
+ if (ret && ret != -ENODEV)
goto out_detach;
}
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[RFC PATCH] vfio: Ignore -ENODEV when getting MSI cookie
When we try to get an MSI cookie for a VFIO device, that can fail if
CONFIG_IOMMU_DMA is not set. In this case iommu_get_msi_cookie() returns
-ENODEV, and that should not be fatal.
Ignore that case and proceed with the initialisation.
This fixes VFIO with a platform device on the Calxeda Midway (no MSIs).
Signed-off-by: Andre Przywara
---
Hi,
not sure this is the right fix, or we should rather check if the
platform doesn't support MSIs at all (which doesn't seem to be easy
to do).
Or is this because arm-smmu.c always reserves an IOMMU_RESV_SW_MSI
region?
Also this seems to be long broken, actually since Eric introduced MSI
support in 4.10-rc3, but at least since the initialisation order was
fixed with f6810c15cf9.
Grateful for any insight.
Cheers,
Andre
drivers/vfio/vfio_iommu_type1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index a177bf2c6683..467e217ef09a 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1786,7 +1786,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
if (resv_msi) {
ret = iommu_get_msi_cookie(domain->domain, resv_msi_base);
- if (ret)
+ if (ret && ret != -ENODEV)
goto out_detach;
}
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 06/11] iommu: arm-smmu: Remove Calxeda secure mode quirk
On Fri, 28 Feb 2020 13:56:46 + Will Deacon wrote: > On Fri, Feb 28, 2020 at 01:42:54PM +0000, Andre Przywara wrote: > > On Fri, 28 Feb 2020 10:50:25 + > > Will Deacon wrote: > > > On Fri, Feb 28, 2020 at 10:25:56AM +, Andre Przywara wrote: > > > > > On Tue, Feb 25, 2020 at 04:01:54PM -0600, Rob Herring wrote: > > > > > > Seems we're leaving the platform support for now, but I think we > > > > > > never > > > > > > actually enabled SMMU support. It's not in the dts either in > > > > > > mainline > > > > > > nor the version I have which should be close to what shipped in > > > > > > firmware. So as long as Andre agrees, this one is good to apply. > > > > > > > > > > > > > > > > Andre? Can I queue this one for 5.7, please? > > > > > > > > I was wondering how much of a pain it is to keep it in? AFAICS there are > > > > other users of the "impl" indirection. If those goes away, I would be > > > > happy to let Calxeda go. > > > > > > The impl stuff is new, so we'll keep it around. The concern is more about > > > testing (see below). > > > > > > > But Eric had the magic DT nodes to get the SMMU working, and I used that > > > > before, with updating the DT either on flash or dynamically via U-Boot. > > > > > > > > > > What did you actually use the SMMU for, though? The > > > 'arm_iommu_create_mapping()' interface isn't widely used and, given that > > > highbank doesn't support KVM, the use-cases for VFIO are pretty limited > > > too. > > > > AFAIK Highbank doesn't have the SMMU, probably mostly for that reason. > > I have a DT snippet for Midway, and that puts the MMIO base at ~36GB, which > > is not possible on Highbank. > > So I think that the quirk is really meant and needed for Midway. > > Sorry, but I don't follow your reasoning here. The MMIO base has nothing > to do with the quirk, It hasn't, but Highbank has no LPAE, so couldn't possible have a device at such an address. And this is the only MMIO address I know of. > although doing some digging it looks like your > conclusion about this applying to Midway (ecx-2000?) is correct: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226095.html Right, thanks for that find. Yes, Midway is the codename for the ECX-2000 SoC product. Cheers, Andre > > > > So I don't know exactly *how* desperate you are with removing this, or > > > > if > > > > there are other reasons than "negative diffstat", but if possible I > > > > would > > > > like to keep it in. > > > > > > It's more that we *do* make quite a lot of changes to the arm-smmu driver > > > and it's never tested with this quirk. If you're stepping up to run smmu > > > tests on my queue for each release on highbank, then great, but otherwise > > > I'd rather not carry the code for fun. The change in diffstat is minimal > > > (we're going to need to hooks for nvidia, who broke things in a different > > > way). > > > > I am about to set up some more sophisticated testing, and will include > > some SMMU bits in it. > > Yes, please. > > Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 06/11] iommu: arm-smmu: Remove Calxeda secure mode quirk
On Fri, 28 Feb 2020 10:50:25 + Will Deacon wrote: > On Fri, Feb 28, 2020 at 10:25:56AM +0000, Andre Przywara wrote: > > On Fri, 28 Feb 2020 10:04:47 + > > Will Deacon wrote: > > > > Hi, > > > > > On Tue, Feb 25, 2020 at 04:01:54PM -0600, Rob Herring wrote: > > > > On Tue, Feb 18, 2020 at 11:20 AM Will Deacon wrote: > > > > > > > > > > > > > > On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote: > > > > > > Cc: Will Deacon > > > > > > Cc: Robin Murphy > > > > > > Cc: Joerg Roedel > > > > > > Cc: iommu@lists.linux-foundation.org > > > > > > Signed-off-by: Rob Herring > > > > > > --- > > > > > > Do not apply yet. > > > > > > > > > > Please? ;) > > > > > > > > > > > drivers/iommu/arm-smmu-impl.c | 43 > > > > > > --- > > > > > > 1 file changed, 43 deletions(-) > > > > > > > > > > Yes, I'm happy to get rid of this. Sadly, I don't think we can remove > > > > > anything from 'struct arm_smmu_impl' because most implementations fall > > > > > just short of perfect. > > > > > > > > > > Anyway, let me know when I can push the button and I'll queue this in > > > > > the arm-smmu tree. > > > > > > > > Seems we're leaving the platform support for now, but I think we never > > > > actually enabled SMMU support. It's not in the dts either in mainline > > > > nor the version I have which should be close to what shipped in > > > > firmware. So as long as Andre agrees, this one is good to apply. > > > > > > Andre? Can I queue this one for 5.7, please? > > > > I was wondering how much of a pain it is to keep it in? AFAICS there are > > other users of the "impl" indirection. If those goes away, I would be > > happy to let Calxeda go. > > The impl stuff is new, so we'll keep it around. The concern is more about > testing (see below). > > > But Eric had the magic DT nodes to get the SMMU working, and I used that > > before, with updating the DT either on flash or dynamically via U-Boot. > > What did you actually use the SMMU for, though? The > 'arm_iommu_create_mapping()' interface isn't widely used and, given that > highbank doesn't support KVM, the use-cases for VFIO are pretty limited > too. AFAIK Highbank doesn't have the SMMU, probably mostly for that reason. I have a DT snippet for Midway, and that puts the MMIO base at ~36GB, which is not possible on Highbank. So I think that the quirk is really meant and needed for Midway. > > So I don't know exactly *how* desperate you are with removing this, or if > > there are other reasons than "negative diffstat", but if possible I would > > like to keep it in. > > It's more that we *do* make quite a lot of changes to the arm-smmu driver > and it's never tested with this quirk. If you're stepping up to run smmu > tests on my queue for each release on highbank, then great, but otherwise > I'd rather not carry the code for fun. The change in diffstat is minimal > (we're going to need to hooks for nvidia, who broke things in a different > way). I am about to set up some more sophisticated testing, and will include some SMMU bits in it. Cheers, Andre. > Also, since the hooks aren't going away, if you /do/ end up using the SMMU > in future, then we could re-add the driver quirk without any fuss. > > Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 06/11] iommu: arm-smmu: Remove Calxeda secure mode quirk
On Fri, 28 Feb 2020 10:04:47 + Will Deacon wrote: Hi, > On Tue, Feb 25, 2020 at 04:01:54PM -0600, Rob Herring wrote: > > On Tue, Feb 18, 2020 at 11:20 AM Will Deacon wrote: > > > > > > On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote: > > > > Cc: Will Deacon > > > > Cc: Robin Murphy > > > > Cc: Joerg Roedel > > > > Cc: iommu@lists.linux-foundation.org > > > > Signed-off-by: Rob Herring > > > > --- > > > > Do not apply yet. > > > > > > Please? ;) > > > > > > > drivers/iommu/arm-smmu-impl.c | 43 --- > > > > 1 file changed, 43 deletions(-) > > > > > > Yes, I'm happy to get rid of this. Sadly, I don't think we can remove > > > anything from 'struct arm_smmu_impl' because most implementations fall > > > just short of perfect. > > > > > > Anyway, let me know when I can push the button and I'll queue this in > > > the arm-smmu tree. > > > > Seems we're leaving the platform support for now, but I think we never > > actually enabled SMMU support. It's not in the dts either in mainline > > nor the version I have which should be close to what shipped in > > firmware. So as long as Andre agrees, this one is good to apply. > > Andre? Can I queue this one for 5.7, please? I was wondering how much of a pain it is to keep it in? AFAICS there are other users of the "impl" indirection. If those goes away, I would be happy to let Calxeda go. But Eric had the magic DT nodes to get the SMMU working, and I used that before, with updating the DT either on flash or dynamically via U-Boot. So I don't know exactly *how* desperate you are with removing this, or if there are other reasons than "negative diffstat", but if possible I would like to keep it in. Cheers, Andre. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 00/11] Removing Calxeda platform support
On Tue, 18 Feb 2020 11:13:10 -0600 Rob Herring wrote: Hi, > Calxeda has been defunct for 6 years now. Use of Calxeda servers carried > on for some time afterwards primarily as distro builders for 32-bit ARM. > AFAIK, those systems have been retired in favor of 32-bit VMs on 64-bit > hosts. > > The other use of Calxeda Midway I'm aware of was testing 32-bit ARM KVM > support as there are few or no other systems with enough RAM and LPAE. Now > 32-bit KVM host support is getting removed[1]. > > While it's not much maintenance to support, I don't care to convert the > Calxeda DT bindings to schema nor fix any resulting errors in the dts files > (which already don't exactly match what's shipping in firmware). While every kernel maintainer seems always happy to take patches with a negative diffstat, I wonder if this is really justification enough to remove a perfectly working platform. I don't really know about any active users, but experience tells that some platforms really are used for quite a long time, even if they are somewhat obscure. N900 or Netwinder, anyone? So to not give the impression that actually *everyone* (from that small subset of people actively reading the kernel list) is happy with that, I think that having support for at least Midway would be useful. On the one hand it's a decent LPAE platform (with memory actually exceeding 4GB), and on the other hand it's something with capable I/O (SATA) and networking, so one can actually stress test the system. Which is the reason I was using that for KVM testing, but even with that probably going away now there remain still some use cases, and be it for general ARM(32) testing. I don't particularly care about the more optional parts like EDAC, cpuidle, or cpufreq, but I wonder if keeping in at least the rather small SATA and XGMAC drivers and basic platform support is feasible. If YAML DT bindings are used as an excuse, I am more than happy to convert those over. And if anyone has any particular gripes with some code, maybe there is a way to fix that instead of removing it? I was always wondering if we could get rid of the mach-highbank directory, for instance. I think most of it is Highbank (Cortex-A9) related. Cheers, Andre > > Rob > > [1] > https://lore.kernel.org/linux-arm-kernel/20200210141324.21090-1-...@kernel.org/ > > Rob Herring (11): > vfio: Remove Calxeda XGMAC reset driver > ata: Remove Calxeda AHCI driver > cpuidle: Remove Calxeda driver > cpufreq: Remove Calxeda driver > EDAC: Remove Calxeda drivers > iommu: arm-smmu: Remove Calxeda secure mode quirk > net: Remove Calxeda XGMAC driver > clk: Remove Calxeda driver > ARM: Remove Calxeda platform support > ARM: dts: Remove Calxeda platforms > dt-bindings: Remove Calxeda platforms bindings > > .../devicetree/bindings/arm/calxeda.yaml | 22 - > .../devicetree/bindings/arm/calxeda/l2ecc.txt | 15 - > .../devicetree/bindings/ata/sata_highbank.txt | 44 - > .../devicetree/bindings/clock/calxeda.txt | 17 - > .../memory-controllers/calxeda-ddr-ctrlr.txt | 16 - > .../devicetree/bindings/net/calxeda-xgmac.txt | 18 - > .../bindings/phy/calxeda-combophy.txt | 17 - > MAINTAINERS | 14 - > arch/arm/Kconfig |2 - > arch/arm/Kconfig.debug| 12 +- > arch/arm/Makefile |1 - > arch/arm/boot/dts/Makefile|3 - > arch/arm/boot/dts/ecx-2000.dts| 103 - > arch/arm/boot/dts/ecx-common.dtsi | 230 -- > arch/arm/boot/dts/highbank.dts| 161 -- > arch/arm/configs/multi_v7_defconfig |5 - > arch/arm/mach-highbank/Kconfig| 19 - > arch/arm/mach-highbank/Makefile |4 - > arch/arm/mach-highbank/core.h | 18 - > arch/arm/mach-highbank/highbank.c | 175 -- > arch/arm/mach-highbank/pm.c | 49 - > arch/arm/mach-highbank/smc.S | 25 - > arch/arm/mach-highbank/sysregs.h | 75 - > arch/arm/mach-highbank/system.c | 22 - > drivers/ata/Kconfig |9 - > drivers/ata/Makefile |1 - > drivers/ata/sata_highbank.c | 635 -- > drivers/clk/Makefile |1 - > drivers/clk/clk-highbank.c| 329 --- > drivers/cpufreq/Kconfig.arm | 10 - > drivers/cpufreq/Makefile |3 +- > drivers/cpufreq/cpufreq-dt-platdev.c |3 - > drivers/cpufreq/highbank-cpufreq.c| 106 - > drivers/cpuidle/Kconfig.arm |7 - > drivers/cpuidle/Makefile |1 - > drivers/cpuidle/cpuidle-calxeda.c | 72 - > drivers/edac/Kconfig | 14 - > drivers/edac/Makefile
Re: [PATCH] iommu/dma: Handle MSI mappings separately
On Mon, 29 Jul 2019 16:32:38 +0100
Robin Murphy wrote:
Hi,
> MSI pages must always be mapped into a device's *current* domain, which
> *might* be the default DMA domain, but might instead be a VFIO domain
> with its own MSI cookie. This subtlety got accidentally lost in the
> streamlining of __iommu_dma_map(), but rather than reintroduce more
> complexity and/or special-casing, it turns out neater to just split this
> path out entirely.
>
> Since iommu_dma_get_msi_page() already duplicates much of what
> __iommu_dma_map() does, it can easily just make the allocation and
> mapping calls directly as well. That way we can further streamline the
> helper back to exclusively operating on DMA domains.
>
> Fixes: b61d271e59d7 ("iommu/dma: Move domain lookup into
> __iommu_dma_{map,unmap}")
> Reported-by: Shameer Kolothum
> Reported-by: Andre Przywara
> Signed-off-by: Robin Murphy
Thanks, that indeed fixes the pass through problem for me, the NVMe and SATA
controller can now happily receive MSIs again.
Tested-by: Andre Przywara
Cheers,
Andre.
> ---
> drivers/iommu/dma-iommu.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index a7f9c3edbcb2..6441197a75ea 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -459,13 +459,11 @@ static dma_addr_t __iommu_dma_map(struct device *dev,
> phys_addr_t phys,
> {
> struct iommu_domain *domain = iommu_get_dma_domain(dev);
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> - size_t iova_off = 0;
> + struct iova_domain *iovad = &cookie->iovad;
> + size_t iova_off = iova_offset(iovad, phys);
> dma_addr_t iova;
>
> - if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
> - iova_off = iova_offset(&cookie->iovad, phys);
> - size = iova_align(&cookie->iovad, size + iova_off);
> - }
> + size = iova_align(iovad, size + iova_off);
>
> iova = iommu_dma_alloc_iova(domain, size, dma_get_mask(dev), dev);
> if (!iova)
> @@ -1147,16 +1145,21 @@ static struct iommu_dma_msi_page
> *iommu_dma_get_msi_page(struct device *dev,
> if (!msi_page)
> return NULL;
>
> - iova = __iommu_dma_map(dev, msi_addr, size, prot);
> - if (iova == DMA_MAPPING_ERROR)
> + iova = iommu_dma_alloc_iova(domain, size, dma_get_mask(dev), dev);
> + if (!iova)
> goto out_free_page;
>
> + if (iommu_map(domain, iova, msi_addr, size, prot))
> + goto out_free_iova;
> +
> INIT_LIST_HEAD(&msi_page->list);
> msi_page->phys = msi_addr;
> msi_page->iova = iova;
> list_add(&msi_page->list, &cookie->msi_page_list);
> return msi_page;
>
> +out_free_iova:
> + iommu_dma_free_iova(cookie, iova, size);
> out_free_page:
> kfree(msi_page);
> return NULL;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
