From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63D46C282DD for ; Thu, 9 Jan 2020 21:45:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3D3D120721 for ; Thu, 9 Jan 2020 21:45:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728425AbgAIVpg (ORCPT ); Thu, 9 Jan 2020 16:45:36 -0500 Received: from mga11.intel.com ([192.55.52.93]:48715 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725763AbgAIVpg (ORCPT ); Thu, 9 Jan 2020 16:45:36 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2020 13:45:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,414,1571727600"; d="scan'208";a="218476526" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by fmsmga008.fm.intel.com with ESMTP; 09 Jan 2020 13:45:35 -0800 Date: Thu, 9 Jan 2020 13:50:38 -0800 From: Jacob Pan To: Lu Baolu Cc: iommu@lists.linux-foundation.org, LKML , Joerg Roedel , David Woodhouse , "Tian, Kevin" , Raj Ashok , Yi Liu , Eric Auger , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v8 04/10] iommu/vt-d: Support flushing more translation cache types Message-ID: <20200109135038.7608d059@jacob-builder> In-Reply-To: <24cc06da-14ec-908d-361d-a8b321b10852@linux.intel.com> References: <1576524252-79116-1-git-send-email-jacob.jun.pan@linux.intel.com> <1576524252-79116-5-git-send-email-jacob.jun.pan@linux.intel.com> <24cc06da-14ec-908d-361d-a8b321b10852@linux.intel.com> Organization: OTC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Dec 2019 10:46:51 +0800 Lu Baolu wrote: > Hi, > > On 12/17/19 3:24 AM, Jacob Pan wrote: > > When Shared Virtual Memory is exposed to a guest via vIOMMU, > > scalable IOTLB invalidation may be passed down from outside IOMMU > > subsystems. This patch adds invalidation functions that can be used > > for additional translation cache types. > > > > Signed-off-by: Jacob Pan > > --- > > drivers/iommu/dmar.c | 46 > > +++++++++++++++++++++++++++++++++++++++++++++ > > drivers/iommu/intel-pasid.c | 3 ++- include/linux/intel-iommu.h | > > 21 +++++++++++++++++---- 3 files changed, 65 insertions(+), 5 > > deletions(-) > > > > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > > index 3acfa6a25fa2..f2f5d75da94a 100644 > > --- a/drivers/iommu/dmar.c > > +++ b/drivers/iommu/dmar.c > > @@ -1348,6 +1348,20 @@ void qi_flush_iotlb(struct intel_iommu > > *iommu, u16 did, u64 addr, qi_submit_sync(&desc, iommu); > > } > > > > +/* PASID-based IOTLB Invalidate */ > > +void qi_flush_iotlb_pasid(struct intel_iommu *iommu, u16 did, u64 > > addr, u32 pasid, > > + unsigned int size_order, u64 granu, int ih) > > +{ > > + struct qi_desc desc = {.qw2 = 0, .qw3 = 0}; > > + > > + desc.qw0 = QI_EIOTLB_PASID(pasid) | QI_EIOTLB_DID(did) | > > + QI_EIOTLB_GRAN(granu) | QI_EIOTLB_TYPE; > > + desc.qw1 = QI_EIOTLB_ADDR(addr) | QI_EIOTLB_IH(ih) | > > + QI_EIOTLB_AM(size_order); > > + > > + qi_submit_sync(&desc, iommu); > > +} > > There's another version of pasid-based iotlb invalidation. > > https://lkml.org/lkml/2019/12/10/2128 > > Let's consider merging them. > Absolutely, the difference i see is that the granularity is explicit here. Here we do invalidation request from the guest. Perhaps, we can look at consolidation once this use case is supported? > Best regards, > baolu [Jacob Pan]