Re: [PATCH v4 0/6] normalize IOMMU dma mode boot options
Hi Zhen, On 2019/4/7 20:41, Zhen Lei wrote: > As Robin Murphy's suggestion: > "It's also not necessarily obvious to the user how this interacts with > IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it > would be better to refactor the whole lot into a single selection of something > like IOMMU_DEFAULT_MODE anyway." > > In this version, I tried to normalize the IOMMU dma mode boot options for all > ARCHs. When IOMMU is enabled, there are 3 dma modes: paasthrough(bypass), > lazy(mapping but defer the IOTLB invalidation), strict. But currently each > ARCHs defined their private boot options, different with each other. For > example, to enable/disable "passthrough", ARM64 use iommu.passthrough=1/0, > X86 use iommu=pt/nopt, PPC/POWERNV use iommu=nobypass. > > > Zhen Lei (6): > iommu: use iommu.dma_mode to replace iommu.passthrough and > iommu.strict > iommu: keep dma mode build options consistent with cmdline options > iommu: add iommu_default_dma_mode_get() helper > s390/pci: use common boot option iommu.dma_mode > powernv/iommu: use common boot option iommu.dma_mode > x86/iommu: use common boot option iommu.dma_mode This will break systems using boot options as now, and I think this is unacceptable. If you want to do so, just introduce iommu.dma_mode on top of those iommu boot options with dma mode boot options unchanged, and iommu.dma_mode is for all archs but compatible with them. Thanks Hanjun
Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.
On 2014-9-18 3:34, Mark Rutland wrote: On Wed, Sep 17, 2014 at 04:37:30PM +0100, Kumar Gala wrote: On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni ganapatrao.kulka...@caviumnetworks.com wrote: From: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com This patch adds property nid to memory node to provide the memory range to numa node id mapping. Signed-off-by: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com — Adding the PPC guys as they’ve been doing NUMA on IBM Power Servers for years with OF/DT. So we should really try and follow what they’ve done. Agreed. Documentation/devicetree/bindings/numa.txt | 58 ++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/numa.txt diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt new file mode 100644 index 000..c4a94f2 --- /dev/null +++ b/Documentation/devicetree/bindings/numa.txt @@ -0,0 +1,58 @@ +== +numa id binding description +== + +== +1 - Introduction +== +The device node property nid(numa node id) can be added to memory Why the quotes? +device node to map the range of memory addresses as defined in property reg. +The property nid maps the memory range to the numa node id, which is used to +find the local and remory pages on numa aware systems. What is a numa node id, exactly, and how is the OS intended to use it? I think Proximity Domain would be more suitably, processors and memory or IOs in the same domain will have better performance than crossing other domains. Thanks Hanjun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
