Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp470806ybt; Mon, 6 Jul 2020 14:01:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx85Dl9Pn2VhIN5jhIihC5hd2Lc/v9pBqJwKc2rv9MyuQF0xWg4bhc7SheK6ZaM/kzu+WX9 X-Received: by 2002:a05:6402:1c07:: with SMTP id ck7mr46279894edb.297.1594069311918; Mon, 06 Jul 2020 14:01:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594069311; cv=none; d=google.com; s=arc-20160816; b=lfHSunl1C9udQqw84i+fL/dK1fOStyG5wSk5oCj0RDCZb0hz4mJpVsM+bqCSgkM83d 7Cw7xOznfXfC94njG2zkWku6j+Yp0ZVxnQz7OU/1QYvcc7hZvJ9WUx6h9PXPmv2zG/vy BsQCNx99TmEd7l7E2LiatfuRxiJTe/zi+9icS6Mmoj9xeP+HgtzxaCdXD7VG5YXRgZZ7 IeMTKKz4qGmserliBP87QruwJaz6CnKLS1n2/Y9N9RwnyxaqEzlj1Fe99Rrcms5iDjkN 9IR+OxH7Cdb6b+4i9fAU/6OsL+eo6IqoXmb+JarPE6Q2eyHgLVoiBLXFEcWO48iRrJ6t 86KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:ironport-sdr:ironport-sdr; bh=Orm4ozZMJl8rxTDqilliZcCpcnUwTsmDDAgYq4nwX0I=; b=ParPAOjq4gIIXC5mBchW6zmp9JPVeUQnbyqClo3OkPQNAIWHWdgIKQsc5GBtVPGYix rJE3aDtFFHnFG4fD1BKkj5hlhWDaCYuRKPPUAUaX7VSsj1iHjVVtaDif3JQMCvtKavSm MwXpkm1PiU3elFNHAWsiBevsDbL7gVh5zrkoWyX2UJeyZON6Iz6GITfdZYOyg4rfe/Rl tgAFjEiIVJXmpFL4d1fTayI4karnt82XZA8v8XFwh/4mvkkLlFEgk41VNMZ5XRvDhn63 bTJDzf+EjPlHNFspc1bChF7BXiv3n92TNS+NR4srmJ5ZCHN40OqkcSiRgFj7xK9XcTVr mdmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n7si13957011edv.74.2020.07.06.14.01.27; Mon, 06 Jul 2020 14:01:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725942AbgGFU7A (ORCPT + 99 others); Mon, 6 Jul 2020 16:59:00 -0400 Received: from mga11.intel.com ([192.55.52.93]:3273 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725892AbgGFU7A (ORCPT ); Mon, 6 Jul 2020 16:59:00 -0400 IronPort-SDR: tTW7E40kVs5dGH8e+ntCDjS5wXqg1ucms4YGVmE7bRmISvn5Vuqg12wnyOtCD13Ev3REnIL4Yo 7zBNL2b4j/5w== X-IronPort-AV: E=McAfee;i="6000,8403,9674"; a="145605313" X-IronPort-AV: E=Sophos;i="5.75,321,1589266800"; d="scan'208";a="145605313" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2020 13:58:59 -0700 IronPort-SDR: 3rvXn4NLKCIRVFAX6OYMotbGWW3F8BZp0YCQDd18XpMnkX/ikCcWy/6zuniWkNQCloi8AQBWUG qs1u15e8crxw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,321,1589266800"; d="scan'208";a="305424906" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by fmsmga004.fm.intel.com with ESMTP; 06 Jul 2020 13:58:59 -0700 Date: Mon, 6 Jul 2020 14:05:17 -0700 From: Jacob Pan To: Auger Eric Cc: iommu@lists.linux-foundation.org, LKML , Lu Baolu , Joerg Roedel , David Woodhouse , Yi Liu , "Tian, Kevin" , Raj Ashok , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH v3 5/7] iommu/vt-d: Fix devTLB flush for vSVA Message-ID: <20200706140517.3f6ca616@jacob-builder> In-Reply-To: References: <1593617636-79385-1-git-send-email-jacob.jun.pan@linux.intel.com> <1593617636-79385-6-git-send-email-jacob.jun.pan@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, 2 Jul 2020 10:39:26 +0200 Auger Eric wrote: > Hi Jacob, Yi, > On 7/1/20 5:33 PM, Jacob Pan wrote: > > From: Liu Yi L > > > > For guest SVA usage, in order to optimize for less VMEXIT, guest > > request of IOTLB flush also includes device TLB. > > > > On the host side, IOMMU driver performs IOTLB and implicit devTLB > > invalidation. When PASID-selective granularity is requested by the > > guest we need to derive the equivalent address range for devTLB > > instead of using the address information in the UAPI data. The > > reason for that is, unlike IOTLB flush, devTLB flush does not > > support PASID-selective granularity. This is to say, we need to set > > the following in the PASID based devTLB invalidation descriptor: > > - entire 64 bit range in address ~(0x1 << 63) > > - S bit = 1 (VT-d CH 6.5.2.6). > > > > Without this fix, device TLB flush range is not set properly for > > PASID selective granularity. This patch also merged devTLB flush > > code for both implicit and explicit cases. > > > > Fixes: 6ee1b77ba3ac ("iommu/vt-d: Add svm/sva invalidate function") > > Acked-by: Lu Baolu > > Signed-off-by: Liu Yi L > > Signed-off-by: Jacob Pan > > --- > > drivers/iommu/intel/iommu.c | 28 ++++++++++++++++++---------- > > 1 file changed, 18 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/iommu/intel/iommu.c > > b/drivers/iommu/intel/iommu.c index 96340da57075..6a0c62c7395c > > 100644 --- a/drivers/iommu/intel/iommu.c > > +++ b/drivers/iommu/intel/iommu.c > > @@ -5408,7 +5408,7 @@ intel_iommu_sva_invalidate(struct > > iommu_domain *domain, struct device *dev, sid = PCI_DEVID(bus, > > devfn); > > /* Size is only valid in address selective invalidation */ > > - if (inv_info->granularity != IOMMU_INV_GRANU_PASID) > > + if (inv_info->granularity == IOMMU_INV_GRANU_ADDR) > > size = > > to_vtd_size(inv_info->addr_info.granule_size, > > inv_info->addr_info.nb_granules); > > @@ -5417,6 +5417,7 @@ intel_iommu_sva_invalidate(struct > > iommu_domain *domain, struct device *dev, IOMMU_CACHE_INV_TYPE_NR) { > > int granu = 0; > > u64 pasid = 0; > > + u64 addr = 0; > > > > granu = to_vtd_granularity(cache_type, > > inv_info->granularity); if (granu == -EINVAL) { > > @@ -5456,24 +5457,31 @@ intel_iommu_sva_invalidate(struct > > iommu_domain *domain, struct device *dev, (granu == > > QI_GRAN_NONG_PASID) ? -1 : 1 << size, inv_info->addr_info.flags & > > IOMMU_INV_ADDR_FLAGS_LEAF); > > + if (!info->ats_enabled) > > + break; > > /* > > * Always flush device IOTLB if ATS is > > enabled. vIOMMU > > * in the guest may assume IOTLB flush is > > inclusive, > > * which is more efficient. > > */ > > - if (info->ats_enabled) > > - qi_flush_dev_iotlb_pasid(iommu, > > sid, > > - info->pfsid, pasid, > > - info->ats_qdep, > > - > > inv_info->addr_info.addr, > > - size); > > - break; > > + fallthrough; > > case IOMMU_CACHE_INV_TYPE_DEV_IOTLB: > > + /* > > + * There is no PASID selective flush for > > device TLB, so > > + * the equivalent of that is we set the > > size to be the > > + * entire range of 64 bit. User only > > provides PASID info > > + * without address info. So we set addr to > > 0. > The "PASID selective flush for device TLB" terminology above sounds a > bit confusing to me. I would rather say Intel device TLB has no > support for OMMU_INV_GRANU_PASID granularity but only supports > IOMMU_INV_GRANU_ADDR. Indeed 6.5.2.6 title is "PASID-based-Device-TLB > Invalidate Descriptor" Sounds good, will rewrite comment accordingly. > > + */ > > + if (inv_info->granularity == > > IOMMU_INV_GRANU_PASID) { > > + size = 64 - VTD_PAGE_SHIFT; > > + addr = 0; > I have my answer for previous patch review question. In that case the > addr is not formatted with the least significant 0 matching the > size_order. > > > + } else if (inv_info->granularity == > > IOMMU_INV_GRANU_ADDR) > > + addr = inv_info->addr_info.addr; > > + > > if (info->ats_enabled) > > qi_flush_dev_iotlb_pasid(iommu, > > sid, info->pfsid, pasid, > > - info->ats_qdep, > > - > > inv_info->addr_info.addr, > > + info->ats_qdep, > > addr, size); > > else > > pr_warn_ratelimited("Passdown > > device IOTLB flush w/o ATS!\n"); > > Besides > > Reviewed-by: Eric Auger > > Thanks > > Eric > [Jacob Pan]