From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lu Baolu Subject: Re: [RFC PATCH 0/6] Auxiliary IOMMU domains and Arm SMMUv3 Date: Mon, 10 Dec 2018 10:57:22 +0800 Message-ID: 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> <20181123112125.GF1586@8bytes.org> <20181207102926.GM16835@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181207102926.GM16835-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> Content-Language: en-US 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: "'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org'" , "Tian, Kevin" Cc: "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 Hi Joerg, On 12/7/18 6:29 PM, 'joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org' wrote: > Hi, > > On Mon, Nov 26, 2018 at 07:29:45AM +0000, Tian, Kevin wrote: >> btw Baolu just reminded me one thing which is worthy of noting here. >> 'primary' vs. 'aux' concept makes sense only when we look from a device >> p.o.v. That binding relationship is not (*should not be*) carry-and-forwarded >> cross devices. every domain must be explicitly attached to other devices >> (instead of implicitly attached being above example), and new primary/aux >> attribute on another device will be decided at attach time. > > Okay, so after all the discussions we had I learned a few more things > about the scalable mode feature and thought a bit longer about how to > best support it in the IOMMU-API. Thanks for thinking about this. > > The concept of sub-domains I initially proposed certainly makes no > sense, but scalable-mode specific attach/detach functions do. So instead > of a sub-domain mode, I'd like to propose device-feature sets. > > The posted patch-set already includes this as device-attributes, but I > don't like this naming as we are really talking about additional > feature sets of a device. So how about we introduce this: > > enum iommu_dev_features { > /* ... */ > IOMMU_DEV_FEAT_AUX, > IOMMU_DEV_FEAT_SVA, > /* ... */ > }; > > /* Check if a device supports a given feature of the IOMMU-API */ > bool iommu_dev_has_feature(struct device *dev, enum iommu_dev_features *feat); Here we pass in a pointer of "enum iommu_dev_features", do we want to return anything here? Best regards, Lu Baolu