From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753588AbdHQRrn (ORCPT ); Thu, 17 Aug 2017 13:47:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39026 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753472AbdHQRra (ORCPT ); Thu, 17 Aug 2017 13:47:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 313A25F796 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com Subject: Re: [RFC v2 2/4] iommu/arm-smmu-v3: Add tlbi_on_map option To: Will Deacon References: <1502459130-6234-1-git-send-email-eric.auger@redhat.com> <1502459130-6234-3-git-send-email-eric.auger@redhat.com> <20170817163424.GC30719@arm.com> 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, tn@semihalf.com, bharat.bhushan@nxp.com From: Auger Eric Message-ID: Date: Thu, 17 Aug 2017 19:47:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170817163424.GC30719@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 17 Aug 2017 17:47:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, On 17/08/2017 18:34, Will Deacon wrote: > On Fri, Aug 11, 2017 at 03:45:28PM +0200, Eric Auger wrote: >> When running a virtual SMMU on a guest we sometimes need to trap >> all changes to the translation structures. This is especially useful >> to integrate with VFIO. This patch adds a new option that forces >> the IO_PGTABLE_QUIRK_TLBI_ON_MAP to be applied on LPAE page tables. >> >> TLBI commands then can be trapped. >> >> Signed-off-by: Eric Auger >> >> --- >> v1 -> v2: >> - rebase on v4.13-rc2 >> --- >> Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 4 ++++ >> drivers/iommu/arm-smmu-v3.c | 5 +++++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt >> index c9abbf3..ebb85e9 100644 >> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt >> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt >> @@ -52,6 +52,10 @@ the PCIe specification. >> devicetree/bindings/interrupt-controller/msi.txt >> for a description of the msi-parent property. >> >> +- tlbi-on-map : invalidate caches whenever there is an update of >> + any remapping structure (updates to not-present or >> + present entries). >> + > > My position on this hasn't changed, so NAK for this patch. If you want to > emulate something outside of the SMMUv3 architecture, please do so, but > don't pretend that it's an SMMUv3. OK understood. I wanted to go down the road and enable DPDK use case using the same solution as Intel. So to me the approach is not adapted to SMMUv3 because - SMMUv3 does not expose anything similar to the Intel Caching Mode (when set, indicates the OS needs to invalidate TLB on map) - SMMUv3 does not expose any IOVA range TLB invalidation command. Do you agree with this conclusion? ACPI enablement was not a showstopper I think. I will see with Peter and other potential users in the community whether it is worth to pursue the efforts on upstreaming the QEMU vSMMUv3 device, considering the VFIO/VHOST integration is made impossible. Thanks Eric > > Will >