Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3
Hi Joerg, On 11/23/18 7:21 PM, j...@8bytes.org wrote: On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote: Can you please elaborate a bit more about the concept of subdomains? From my point of view, an aux-domain is a normal un-managed domain which has a PASID and could be attached to any ADIs through the aux-domain specific attach/detach APIs. It could also be attached to a device with the existing domain_attach/detach_device() APIs at the same time, hence mdev and pci devices in a vfio container could share a domain. Okay, let's think a bit about having aux-specific attach/detach functions, in the end I don't insist on my proposal as long as the IOMMU-API extensions are clean, consistent, and have well defined semantics. If we have aux-domain specific attach/detach functions like iommu_aux_domain_attach/detach(), what happens when the primary domain of the device is changed with iommu_attach/detach()? 1) Will the aux-domains stay in place? If yes, how does this work in setups where the pasid-bound page-tables are guest-owned and translated through the primary domain page-tables? Are you thinking about guest SVA? In this case, guest SVA will be translated through the aux domain page-tables. So, we can safely change the primary domain with aux-domains staying there. Conceptually, the primary domain means the existing domain which is for all Request ID based (a.k.a. transfers without PASID) translations. Any transfer with PASID will not go through the primary domain. 2) Will the aux-domains be unbound too? In that case, if the primary domain is re-used, will the aux-domains be implicitly bound too when iommu_device_attach() is called? 3) Do we just disallow changing the primary domain through that interface as long as there are aux-domains or mm_structs bound to the device? Using option 2) or 3) would mean that the aux-domains are still bound to the primary domain, but that is not reflected in the API. Further, if an aux-domain is just a normal domain (struct iommu_domain), what happens when a domain that was used as a primary domain and has bound aux-domains to it, is bound with iommu_aux_domain_attach() to another domain? As you can see, this design decission raises a lot of questions, but maybe we can work it out and find a solution we all agree on. Regards, Joerg Best regards, Lu Baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE
On 23-11-18, 15:24, Anshuman Khandual wrote:
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -386,7 +386,8 @@ EXPORT_SYMBOL(dma_issue_pending_all);
> static bool dma_chan_is_local(struct dma_chan *chan, int cpu)
> {
> int node = dev_to_node(chan->device->dev);
> - return node == -1 || cpumask_test_cpu(cpu, cpumask_of_node(node));
> + return node == NUMA_NO_NODE ||
> + cpumask_test_cpu(cpu, cpumask_of_node(node));
> }
I do not see dev_to_node being updated first, that returns -1 so I would
prefer to check for -1 unless it return NUMA_NO_NODE
--
~Vinod
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE
On 11/24/2018 05:14 AM, Andrew Morton wrote: > On Fri, 23 Nov 2018 15:24:16 +0530 Anshuman Khandual > wrote: > >> At present there are multiple places where invalid node number is encoded >> as -1. Even though implicitly understood it is always better to have macros >> in there. Replace these open encodings for an invalid node number with the >> global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like >> 'invalid node' from various places redirecting them to a common definition. >> >> ... >> >> Build tested this with multiple cross compiler options like alpha, sparc, >> arm64, x86, powerpc, powerpc64le etc with their default config which might >> not have compiled tested all driver related changes. I will appreciate >> folks giving this a test in their respective build environment. >> >> All these places for replacement were found by running the following grep >> patterns on the entire kernel code. Please let me know if this might have >> missed some instances. This might also have replaced some false positives. >> I will appreciate suggestions, inputs and review. >> >> 1. git grep "nid == -1" >> 2. git grep "node == -1" >> 3. git grep "nid = -1" >> 4. git grep "node = -1" > > The build testing is good, but I worry that some of the affected files > don't clearly have numa.h in their include paths, for the NUMA_NO_NODE > definition. > > The first thing I looked it is arch/powerpc/include/asm/pci-bridge.h. > Maybe it somehow manages to include numa.h via some nested include, but > if so, is that reliable across all config combinations and as code > evolves? > > So I think that the patch should have added an explicit include of > numa.h, especially in cases where the affected file previously had no > references to any of the things which numa.h defines. Fair enough. Will include numa.h in those particular files. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
