From mboxrd@z Thu Jan 1 00:00:00 1970 From: "joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org" Subject: Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3 Date: Fri, 23 Nov 2018 12:21:25 +0100 Message-ID: <20181123112125.GF1586@8bytes.org> References: <20181019181158.2395-1-jean-philippe.brucker@arm.com> <11f88122-afd3-a34c-3cd4-db681bf5498b@arm.com> <20181106162539.4gmkvg57mja3bn7k@8bytes.org> <20181107164323.GA19831@8bytes.org> <758bb120-5bc0-1e2d-ccd0-9be0bcc5d8bc@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <758bb120-5bc0-1e2d-ccd0-9be0bcc5d8bc-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Lu Baolu Cc: "Tian, Kevin" , "alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , Jean-Philippe Brucker , "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" , "will.deacon-5wv7dgnIgG8@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Robin Murphy , "christian.koenig-5C7GfCeVMHo@public.gmane.org" List-Id: iommu@lists.linux-foundation.org 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? 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