From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [RFC 0/2] arm-smmu-v3 tlbi-on-map option Date: Wed, 12 Jul 2017 18:54:56 +0100 Message-ID: <20170712175454.GF15191@arm.com> References: <1499613303-30173-1-git-send-email-eric.auger@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1499613303-30173-1-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@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: Eric Auger Cc: mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marc.Zyngier-5wv7dgnIgG8@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org List-Id: iommu@lists.linux-foundation.org Hi Eric, On Sun, Jul 09, 2017 at 05:15:01PM +0200, Eric Auger wrote: > This series adds a new tlbi-on-map option to the smmuv3 driver. > When set, the IO_PGTABLE_QUIRK_TLBI_ON_MAP quirk is applied for > LPAE tables and the smmuv3 driver sends TLB invalidations on map. > > This mode is useful when running the driver on a guest as it allows > the virtualizer to trap any change to the translation structures. > This is similar to the Intel vtd caching mode (CM). > > This is especially needed for VFIO integration integration where > guest mappings must be applied to the physical IOMMU. > > At the moment the option only is available for DT probing. I'm really not a fan of this approach. If a virtual IOMMU implementation is advertising itself as an SMMUv3, then it should adhere to the SMMUv3 architecture and not require non-standard behaviour from the driver. If we're going to allow that, then we're better off going the extra mile and using a PV approach. Given that the the SMMU3 architecture does *not* require TLBI on map, then I don't think we should be quirking our behaviour in this way. The fact that you only have this implemented for DT is the canary in the coal mine imo. Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752730AbdGLRy4 (ORCPT ); Wed, 12 Jul 2017 13:54:56 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:57464 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752617AbdGLRyy (ORCPT ); Wed, 12 Jul 2017 13:54:54 -0400 Date: Wed, 12 Jul 2017 18:54:56 +0100 From: Will Deacon To: Eric Auger Cc: eric.auger.pro@gmail.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, robin.murphy@arm.com, Jean-Philippe.Brucker@arm.com, christoffer.dall@linaro.org, Marc.Zyngier@arm.com, alex.williamson@redhat.com, peterx@redhat.com, mst@redhat.com Subject: Re: [RFC 0/2] arm-smmu-v3 tlbi-on-map option Message-ID: <20170712175454.GF15191@arm.com> References: <1499613303-30173-1-git-send-email-eric.auger@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1499613303-30173-1-git-send-email-eric.auger@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On Sun, Jul 09, 2017 at 05:15:01PM +0200, Eric Auger wrote: > This series adds a new tlbi-on-map option to the smmuv3 driver. > When set, the IO_PGTABLE_QUIRK_TLBI_ON_MAP quirk is applied for > LPAE tables and the smmuv3 driver sends TLB invalidations on map. > > This mode is useful when running the driver on a guest as it allows > the virtualizer to trap any change to the translation structures. > This is similar to the Intel vtd caching mode (CM). > > This is especially needed for VFIO integration integration where > guest mappings must be applied to the physical IOMMU. > > At the moment the option only is available for DT probing. I'm really not a fan of this approach. If a virtual IOMMU implementation is advertising itself as an SMMUv3, then it should adhere to the SMMUv3 architecture and not require non-standard behaviour from the driver. If we're going to allow that, then we're better off going the extra mile and using a PV approach. Given that the the SMMU3 architecture does *not* require TLBI on map, then I don't think we should be quirking our behaviour in this way. The fact that you only have this implemented for DT is the canary in the coal mine imo. Will