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: Wed, 12 Dec 2018 10:22:37 +0100 Message-ID: <20181212092237.GS16835@8bytes.org> References: <20181107164323.GA19831@8bytes.org> <758bb120-5bc0-1e2d-ccd0-9be0bcc5d8bc@linux.intel.com> <20181123112125.GF1586@8bytes.org> <20181207102926.GM16835@8bytes.org> <20181210085745.GN16835@8bytes.org> <4be63d12-fa1c-b180-761b-5e8ceed58545@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4be63d12-fa1c-b180-761b-5e8ceed58545-5wv7dgnIgG8@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: Jean-Philippe Brucker Cc: "Tian, Kevin" , "alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" , Will Deacon , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Robin Murphy , "christian.koenig-5C7GfCeVMHo@public.gmane.org" List-Id: iommu@lists.linux-foundation.org On Tue, Dec 11, 2018 at 06:34:23PM +0000, Jean-Philippe Brucker wrote: > The cost of enabling those features for a device does seem negligible. > For the SMMU we need to allocate about 70k of additional memory for the > initial PASID table, but enabling the PASID cap shouldn't add any > overhead otherwise. Same for PRI, shouldn't add any overhead. Okay, the memory requirements are a pretty good case for an enable/disable part in the API. > As for ATS, it supposedly makes things faster, although it does mean > more invalidation requests. There currently is a global pci=noats > parameter, but maybe we need something with finer granularity to > enable/disable it per device? Yeah, I don't object against this, but I think this is a matter of PCI code. The IOMMUs should just enable ATS when it is available. PCI core can fail to enable it if requested by the user. Regards, Joerg