Re: [PATCH] intel-iommu: Synchronize gcmd value with global command register
On Wed, Apr 03, 2013 at 09:24:39AM +0100, David Woodhouse wrote: On Wed, 2013-04-03 at 16:11 +0900, Takao Indoh wrote: Yeah, you are right. I forgot such a case. If you disable translation and there's some device still doing DMA, it's going to scribble over random areas of memory. You really want to have translation enabled and all the page tables *cleared*, during kexec. I think it's fair to insist that the secondary kernel should use the IOMMU if the first one did. Do we really need to insist on that? The IOMMU initialization on x86 happens after the kernel scanned and enumerated the PCI bus. While doing this the kernel (at least it should) disables all devices it finds. So when the IOMMU init code runs we should be safe from any in-flight DMA and can either disable translation or re-initialize it for the kdump kernel. Until then translation needs to stay enabled of course, so that the old page-tables are still used and in-flight DMA doesn't corrupt any data. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
Hi Rob, On Fri, Apr 05, 2013 at 05:43:06PM +0100, Rob Herring wrote: On 04/04/2013 11:50 AM, Will Deacon wrote: This patch adds a description of the device tree binding for the ARM System MMU architecture. Cc: Rob Herring robherri...@gmail.com Cc: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Will Deacon will.dea...@arm.com --- Hello, The driver for this is still a WIP. Both Andreas and myself have prototype code, but we're planning to merge that together to get something more general. Deciding on the binding is a good first step. Thanks for getting this out. No problem. All comments welcome, Will .../devicetree/bindings/iommu/arm,smmu.txt | 61 ++ 1 file changed, 61 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt new file mode 100644 index 000..938325f --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -0,0 +1,61 @@ +* ARM System MMU Architecture Implementation + +ARM SoCs may contain an implementation of the ARM System Memory +Management Unit Architecture, which can be used to provide 1 or 2 stages +of address translation to bus masters external to the CPU. + +The SMMU may also raise interrupts in response to various fault +conditions. + +** System MMU required properties: + +- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2 + depending on the version of the architecture + implemented. We can keep these, but we should have specific models like arm,smmu-400, etc. as well. Ok, if distinctions need to be between MMU-400 and a v1 implementation, then we can add those strings later. + +- reg : Base address and size of the SMMU. + +- #global-interrupts : The number of global interrupts exposed by the + device. + +- interrupts: Interrupt list, with the first #global-irqs entries + corresponding to the global interrupts and any + following entries corresponding to context interrupts, + specified in order of their indexing by the SMMU. + +- mmu-masters : A list of phandles to device nodes representing bus + masters for which the SMMU can provide a translation. + +- stream-ids: A list of 16-bit values corresponding to the StreamIDs + for the devices listed in the mmu-masters property. + This list must be same length as mmu-masters, so + masters with multiple stream-ids will have multiple + entries in mmu-masters. Your example below is actually 32-bit values in the DTB. You can annotate them to actually be 16-bit if you want. But I would just leave them as 32-bit. I'm also parsing them as u32 in my driver, so yes, u32 it is! + +** System MMU optional properties: + +- smmu-parent : When multiple SMMUs are chained together, this + property can be used to provide a phandle to the + parent SMMU (that is the next SMMU on the path going + from the mmu-masters towards memory) node for this + SMMU. Does the SMMU need to know if it is coherent or not? You mean with respect to table walks? That's actually probable from the device (along with a whole bunch of other parameters) using SMMU_IDR0. I'll fix up the other comments and send out a v2 next week. Cheers for the review, Will ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
On 04/04/2013 11:50 AM, Will Deacon wrote:
This patch adds a description of the device tree binding for the ARM
System MMU architecture.
Cc: Rob Herring robherri...@gmail.com
Cc: Andreas Herrmann andreas.herrm...@calxeda.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
Hello,
The driver for this is still a WIP. Both Andreas and myself have prototype
code, but we're planning to merge that together to get something more
general. Deciding on the binding is a good first step.
Thanks for getting this out.
All comments welcome,
Will
.../devicetree/bindings/iommu/arm,smmu.txt | 61
++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 000..938325f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,61 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2
+ depending on the version of the architecture
+ implemented.
We can keep these, but we should have specific models like arm,smmu-400,
etc. as well.
+
+- reg : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+ device.
+
+- interrupts: Interrupt list, with the first #global-irqs entries
+ corresponding to the global interrupts and any
+ following entries corresponding to context interrupts,
+ specified in order of their indexing by the SMMU.
+
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation.
+
+- stream-ids: A list of 16-bit values corresponding to the StreamIDs
+ for the devices listed in the mmu-masters property.
+ This list must be same length as mmu-masters, so
+ masters with multiple stream-ids will have multiple
+ entries in mmu-masters.
Your example below is actually 32-bit values in the DTB. You can
annotate them to actually be 16-bit if you want. But I would just leave
them as 32-bit.
+
+** System MMU optional properties:
+
+- smmu-parent : When multiple SMMUs are chained together, this
+ property can be used to provide a phandle to the
+ parent SMMU (that is the next SMMU on the path going
+ from the mmu-masters towards memory) node for this
+ SMMU.
Does the SMMU need to know if it is coherent or not?
Rob
+
+Example:
+
+smmu {
+compatible = arm,smmu-v1;
+reg = 0xba5e 0x1;
+#global-interrupts = 2;
+interrupts = 0 32 4,
+ 0 33 4,
+ 0 34 4, /* This is the first context
interrupt */
+ 0 35 4,
+ 0 36 4,
+ 0 37 4;
+mmu-masters = dma0,
+ dma0,
+ dma1;
+stream-ids = 0xd01d,
+ 0xd01e,
+ 0xd11c;
+};
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
On 4/4/2013 9:50 AM, Will Deacon wrote:
This patch adds a description of the device tree binding for the ARM
System MMU architecture.
Cc: Rob Herring robherri...@gmail.com
Cc: Andreas Herrmann andreas.herrm...@calxeda.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
Hello,
The driver for this is still a WIP. Both Andreas and myself have prototype
code, but we're planning to merge that together to get something more
general. Deciding on the binding is a good first step.
All comments welcome,
Will
.../devicetree/bindings/iommu/arm,smmu.txt | 61
++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 000..938325f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,61 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible: Should be one of arm,smmu-v1 or arm,smmu-v2
+ depending on the version of the architecture
+ implemented.
+
+- reg : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+ device.
+
+- interrupts: Interrupt list, with the first #global-irqs entries
+ corresponding to the global interrupts and any
+ following entries corresponding to context interrupts,
+ specified in order of their indexing by the SMMU.
+
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation.
I am not sure I understand the use of mmu-masters. I would imagine that
the bus masters themselves would have phandles to their respective SMMUs
that provides the translation.
+
+- stream-ids: A list of 16-bit values corresponding to the StreamIDs
+ for the devices listed in the mmu-masters property.
+ This list must be same length as mmu-masters, so
+ masters with multiple stream-ids will have multiple
+ entries in mmu-masters.
+
Why are the stream IDs (SIDs) coupled with the bus masters in this way?
You are probably following a different pattern than we do. Our SMMU
driver programs the SMMU SIDs and does not really know or care which
mmu-master it belongs to.
+** System MMU optional properties:
+
+- smmu-parent : When multiple SMMUs are chained together, this
+ property can be used to provide a phandle to the
+ parent SMMU (that is the next SMMU on the path going
+ from the mmu-masters towards memory) node for this
+ SMMU.
+
+Example:
+
+smmu {
+compatible = arm,smmu-v1;
+reg = 0xba5e 0x1;
+#global-interrupts = 2;
+interrupts = 0 32 4,
+ 0 33 4,
+ 0 34 4, /* This is the first context
interrupt */
+ 0 35 4,
+ 0 36 4,
+ 0 37 4;
+mmu-masters = dma0,
+ dma0,
+ dma1;
+stream-ids = 0xd01d,
+ 0xd01e,
+ 0xd11c;
+};
Hi Will,
Please see my comments above. I would like to work with you on defining
the bindings for System MMU. We have had System MMU DT bindings for some
time and I'd like to share what we are doing in hope that we can merge
something that works for all of us.
We use some of the same properties but we have a lot more. We also model
the context banks as children of each SMMU in an object-oriented way.
Here is our current binding for SMMUv1:
* Qualcomm MSM IOMMU v1
Required properties:
- compatible : one of:
- qcom,msm-smmu-v1
- reg : offset and length of the register set for the device. Optional
offset and length for clock register for additional clock that
needs to be turned on for access to this IOMMU.
- reg-names: iommu_base, clk_base (optional)
- label: name of this IOMMU instance.
Optional properties:
- qcom,iommu-secure-id : Secure identifier for the IOMMU block
- vdd-supply : vdd-supply: phandle to GDSC regulator controlling this IOMMU.
- qcom,alt-vdd-supply : Alternative regulator needed to access IOMMU
configuration
Re: RFC: vfio API changes needed for powerpc (v3)
On 04/04/2013 05:10:27 PM, Yoder Stuart-B08248 wrote:
/*
* VFIO_IOMMU_PAMU_UNMAP_MSI_BANK
*
* Unmaps the MSI bank at the specified iova.
* Caller provides struct vfio_pamu_msi_bank_unmap with all fields
set.
* Operates on VFIO file descriptor (/dev/vfio/vfio).
* Return: 0 on success, -errno on failure
*/
struct vfio_pamu_msi_bank_unmap {
__u32 argsz;
__u32 flags; /* no flags currently */
__u64 iova; /* the iova to be unmapped to */
};
#define VFIO_IOMMU_PAMU_UNMAP_MSI_BANK _IO(VFIO_TYPE, VFIO_BASE + x,
struct vfio_pamu_msi_bank_unmap )
What happens if a normal unmap call is done on the MSI iova? Do we
need a separate unmap?
-Scott
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
