Message ID | 20240229033138.3379560-1-haifeng.zhao@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-86094-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2097:b0:108:e6aa:91d0 with SMTP id gs23csp176535dyb; Wed, 28 Feb 2024 20:51:04 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXfKkUpLwhZboOOReqPwOpAI911U81QtjaOm3qC7ErOo8HZkZNyVKbeKRizJtruDtE3t1DOj55PaMwRVH1G2YTRmsvKhg== X-Google-Smtp-Source: AGHT+IGwxKWX3gvEaGNkBlLdy50OVxGpR1s8xIltus5AWm7AzgeEOCwMzaJz3f36elttbpNjvBAm X-Received: by 2002:a17:90a:8b02:b0:29b:789:802a with SMTP id y2-20020a17090a8b0200b0029b0789802amr1223546pjn.31.1709182264195; Wed, 28 Feb 2024 20:51:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709182264; cv=pass; d=google.com; s=arc-20160816; b=ss/cUCCkHlFUm9WUTWhyFBcrfafns5V2U9hQuWtkt2f2UROzt2YjOKWvR1ZovjWGBW HhVYJK5K2rrWC7MipDeURz0zfueDDf6CYUOxxZVUnDLTQ7bkV9L3dCxTh2K3ZRmXN88u 1vfduJ6BJ9ORmwtHLX6MIN8MhWewFCn3VrBc1LPtwqkECWavuGD0Sqp/cQBOZifmBdq5 3NUy7EApnXcgiFcbRVo2CFrKZEHOZ1mLthFO4aOXot2kj981+oo7Xmyn31R2nn1SnNpe X5sQOUGw8G6nxaxdkYKNNFK94ErqoCV2ccBqjLqW4yE0JHb9KwLJfHX1IdzcMXrmRbDx LWWQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=cT9tgRQ+ilHNkoPzH0oiSWaR0wWYv1CmBKh1m0+rsuA=; fh=CcvPup2qFKOU+RSlxpmYRdCRaLkLlngXWCtLCjXBjlA=; b=pPy0+zuBJoC3Aibbu09pPh+FuGm7fsOEM/9xKjQfnuOxXiTirep+p8toYK4UNfyNvX fIxb7wuaQG7bp89ap/Q0xb54yKoTsWrmb1DVlHD8+8a/62Xle051Jc5jAgdjUxN1X/Tx OyppsBr0UgOeGNmEbkiZ2lEO29pJj7yyZ09Av+ysqKnONbFO31NTviYinfvCzb7X+4qr 0WsheU73Lkl4Io6/TWeL7vDBUSnU4rt2msWF08yur3nfwEUuD8WCSkbWmoeXZmVqi/So n5UiYkusFa0SS1L8ZefU8443wNxBpOZqsZ8wlUq2OU26NvmDgMZJfmpCM5C1DRABUP9j 7y/A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=T7HuM4kW; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-86094-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-86094-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id oo10-20020a17090b1c8a00b0029a84892664si749637pjb.27.2024.02.28.20.51.04 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Feb 2024 20:51:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-86094-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=T7HuM4kW; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-86094-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-86094-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7362628807A for <ouuuleilei@gmail.com>; Thu, 29 Feb 2024 03:32:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F00F13770D; Thu, 29 Feb 2024 03:31:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="T7HuM4kW" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCB7D224DC for <linux-kernel@vger.kernel.org>; Thu, 29 Feb 2024 03:31:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709177516; cv=none; b=Il4crbyKLTXkzkFJI0Ue4c9QmuhdBprasC07MiiocgFVrFrj4SkEYEHqLw5jfQPj3gVfsV532pgf1KbWRC1nZywCTAnFRXddzdQyLRT4bdi8TDjxLPJxLsqFLXNpFnDyE8sXUaa4vushCEzXKV7fHUCht3SpDveg+gIi9wmv8sg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709177516; c=relaxed/simple; bh=4cTVcJ3SUxPHYzHn2pDBkxHL7saiq6NY+ySDwsITglc=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=KpM6OGOJRThgG/XasTXVfLHp8Qbm3eWTKRX4gZebyGIeRNvGpTvytKrJ5GrsI0sXsbVlaisCalkEcn7jWjRlGWBVUM1DiGFQAZfGyWwRll+DsHRqazhSA2H8F3qhB6BA3aWx+yMPWE2HcSfhwGifhGolip/icRJlCzCHsAcnUSg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=T7HuM4kW; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1709177514; x=1740713514; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4cTVcJ3SUxPHYzHn2pDBkxHL7saiq6NY+ySDwsITglc=; b=T7HuM4kWJCU5jV+0OsBIU8Re1nDdfqgbg1CgO5xq1R36WokDE/y5+oFL lg/CvIsY1Xa1+wJ4J1zV3bda1RmodFriw7Q5/kIwtIAGQMJaC7E8OJrCc YwcN50/1bfFOaqGCMc0xenxpmXx/41CWQJAkhDSF+HicoHH2TGAvTsA47 dKqyED168uGi/ASvsWlj/zHQyTYleQYSzMxJUyQpCr5UyyD9MjkaizB0W 9il3dNnY9T3Oi22ip4rqTHSx/Dwre4Y/tZHOiT60EcegRXRRuU0+ZYAuc DH3l2e0MbP7UXJAoxVdjoFNgwnXIG+23P5RQJ9xbsYnSgk3sRWtOGZqHq A==; X-IronPort-AV: E=McAfee;i="6600,9927,10998"; a="14772552" X-IronPort-AV: E=Sophos;i="6.06,192,1705392000"; d="scan'208";a="14772552" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Feb 2024 19:31:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,192,1705392000"; d="scan'208";a="8232101" Received: from unknown (HELO ply01-vm-store.amr.corp.intel.com) ([10.238.153.201]) by orviesa008.jf.intel.com with ESMTP; 28 Feb 2024 19:31:45 -0800 From: Ethan Zhao <haifeng.zhao@linux.intel.com> To: baolu.lu@linux.intel.com, bhelgaas@google.com, robin.murphy@arm.com, jgg@ziepe.ca Cc: kevin.tian@intel.com, dwmw2@infradead.org, will@kernel.org, lukas@wunner.de, yi.l.liu@intel.com, dan.carpenter@linaro.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Ethan Zhao <haifeng.zhao@linux.intel.com> Subject: [PATCH] iommu/vt-d: avoid sending explicit ATS invalidation request to released device Date: Wed, 28 Feb 2024 22:31:38 -0500 Message-Id: <20240229033138.3379560-1-haifeng.zhao@linux.intel.com> X-Mailer: git-send-email 2.31.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792207501753557168 X-GMAIL-MSGID: 1792207501753557168 |
Series |
iommu/vt-d: avoid sending explicit ATS invalidation request to released device
|
|
Commit Message
Ethan Zhao
Feb. 29, 2024, 3:31 a.m. UTC
The introduction of per iommu device rbtree also defines the lifetime of
interoperation between iommu and devices, if the device has been released
from device rbtree, no need to send ATS invalidation request to it anymore,
thus avoid the possibility of later ITE fault to be triggered.
This is part of the followup of prior proposed patchset
https://do-db2.lkml.org/lkml/2024/2/22/350
To make sure all the devTLB entries to be invalidated in the device release
path, do implict invalidation by fapping the E bit of ATS control register.
see PCIe spec v6.2, sec 10.3.7 implicit invalidation events.
Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface")
Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com>
---
drivers/iommu/intel/iommu.c | 6 ++++++
drivers/iommu/intel/pasid.c | 7 +++++++
2 files changed, 13 insertions(+)
Comments
On 2/29/2024 11:31 AM, Ethan Zhao wrote: > The introduction of per iommu device rbtree also defines the lifetime of > interoperation between iommu and devices, if the device has been released > from device rbtree, no need to send ATS invalidation request to it anymore, > thus avoid the possibility of later ITE fault to be triggered. > > This is part of the followup of prior proposed patchset > > https://do-db2.lkml.org/lkml/2024/2/22/350 > > To make sure all the devTLB entries to be invalidated in the device release > path, do implict invalidation by fapping the E bit of ATS control register. > see PCIe spec v6.2, sec 10.3.7 implicit invalidation events. > > Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") > Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 6 ++++++ > drivers/iommu/intel/pasid.c | 7 +++++++ > 2 files changed, 13 insertions(+) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 6743fe6c7a36..b85d88ccb4b0 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -1368,6 +1368,12 @@ static void iommu_disable_pci_caps(struct device_domain_info *info) > pdev = to_pci_dev(info->dev); > > if (info->ats_enabled) { > + pci_disable_ats(pdev); > + /* > + * flap the E bit of ATS control register to do implicit > + * ATS invlidation, see PCIe spec v6.2, sec 10.3.7 > + */ > + pci_enable_ats(pdev, VTD_PAGE_SHIFT); > pci_disable_ats(pdev); > info->ats_enabled = 0; > domain_update_iotlb(info->domain); > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c > index 108158e2b907..5f13e017a12c 100644 > --- a/drivers/iommu/intel/pasid.c > +++ b/drivers/iommu/intel/pasid.c > @@ -215,6 +215,13 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, > return; > > sid = info->bus << 8 | info->devfn; > + /* > + * If device has been released from rbtree, no need to send ATS > + * Invalidation request anymore, that could cause ITE fault. > + */ > + if (!device_rbtree_find(iommu, sid)) > + return; > + > qdep = info->ats_qdep; > pfsid = info->pfsid; > This patch based on Baolu's per iommu device rbtree patchset https://github.com/LuBaolu/intel-iommu/commits/rbtree-for-device-info-v2 Thanks, Ethan
On Wed, Feb 28, 2024 at 10:31:38PM -0500, Ethan Zhao wrote: > The introduction of per iommu device rbtree also defines the lifetime of > interoperation between iommu and devices, if the device has been released > from device rbtree, no need to send ATS invalidation request to it anymore, > thus avoid the possibility of later ITE fault to be triggered. > > This is part of the followup of prior proposed patchset > > https://do-db2.lkml.org/lkml/2024/2/22/350 Please use https://lore.kernel.org/ URLs instead. This one looks like https://lore.kernel.org/r/20240222090251.2849702-1-haifeng.zhao@linux.intel.com/ > To make sure all the devTLB entries to be invalidated in the device release > path, do implict invalidation by fapping the E bit of ATS control register. > see PCIe spec v6.2, sec 10.3.7 implicit invalidation events. s/implict/implicit/ s/fapping/?/ (no idea :) "flipping"? Oh, probably "flapping" per the comment below. But I think "flapping" is ambiguous; "setting" would be better) s/v6.2/r6.2/ (also below in comment) > Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") > Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 6 ++++++ > drivers/iommu/intel/pasid.c | 7 +++++++ > 2 files changed, 13 insertions(+) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 6743fe6c7a36..b85d88ccb4b0 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -1368,6 +1368,12 @@ static void iommu_disable_pci_caps(struct device_domain_info *info) > pdev = to_pci_dev(info->dev); > > if (info->ats_enabled) { > + pci_disable_ats(pdev); > + /* > + * flap the E bit of ATS control register to do implicit > + * ATS invlidation, see PCIe spec v6.2, sec 10.3.7 s/invlidation/invalidation/ I would put the comment above the pci_disable_ats(), so it looks like this: /* comment ... */ pci_disable_ats(pdev); pci_enable_ats(pdev, VTD_PAGE_SHIFT); pci_disable_ats(pdev); because the spec says the E field must change from Clear to Set to cause invalidation of all ATC entries, so it's important to see that we clear E first, then set it. > + */ > + pci_enable_ats(pdev, VTD_PAGE_SHIFT); > pci_disable_ats(pdev); > info->ats_enabled = 0; > domain_update_iotlb(info->domain); > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c > index 108158e2b907..5f13e017a12c 100644 > --- a/drivers/iommu/intel/pasid.c > +++ b/drivers/iommu/intel/pasid.c > @@ -215,6 +215,13 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, > return; > > sid = info->bus << 8 | info->devfn; > + /* > + * If device has been released from rbtree, no need to send ATS > + * Invalidation request anymore, that could cause ITE fault. > + */ > + if (!device_rbtree_find(iommu, sid)) > + return; > + > qdep = info->ats_qdep; > pfsid = info->pfsid; > > -- > 2.31.1 >
On 3/1/2024 5:06 AM, Bjorn Helgaas wrote: > On Wed, Feb 28, 2024 at 10:31:38PM -0500, Ethan Zhao wrote: >> The introduction of per iommu device rbtree also defines the lifetime of >> interoperation between iommu and devices, if the device has been released >> from device rbtree, no need to send ATS invalidation request to it anymore, >> thus avoid the possibility of later ITE fault to be triggered. >> >> This is part of the followup of prior proposed patchset >> >> https://do-db2.lkml.org/lkml/2024/2/22/350 > Please use https://lore.kernel.org/ URLs instead. This one looks like > https://lore.kernel.org/r/20240222090251.2849702-1-haifeng.zhao@linux.intel.com/ > >> To make sure all the devTLB entries to be invalidated in the device release >> path, do implict invalidation by fapping the E bit of ATS control register. >> see PCIe spec v6.2, sec 10.3.7 implicit invalidation events. > s/implict/implicit/ > > s/fapping/?/ (no idea :) "flipping"? Oh, probably "flapping" per the > comment below. But I think "flapping" is ambiguous; "setting" would be > better) Yup, like the memory bit flipping, no idea what is the right word, setting one bit to 0, then 1, then back to 0. perhaps details the setting action 0-->1-->0 ? > s/v6.2/r6.2/ (also below in comment) got it. > >> Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") >> Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> >> --- >> drivers/iommu/intel/iommu.c | 6 ++++++ >> drivers/iommu/intel/pasid.c | 7 +++++++ >> 2 files changed, 13 insertions(+) >> >> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c >> index 6743fe6c7a36..b85d88ccb4b0 100644 >> --- a/drivers/iommu/intel/iommu.c >> +++ b/drivers/iommu/intel/iommu.c >> @@ -1368,6 +1368,12 @@ static void iommu_disable_pci_caps(struct device_domain_info *info) >> pdev = to_pci_dev(info->dev); >> >> if (info->ats_enabled) { >> + pci_disable_ats(pdev); >> + /* >> + * flap the E bit of ATS control register to do implicit >> + * ATS invlidation, see PCIe spec v6.2, sec 10.3.7 > s/invlidation/invalidation/ > > I would put the comment above the pci_disable_ats(), so it looks like > this: > > /* comment ... */ > pci_disable_ats(pdev); > pci_enable_ats(pdev, VTD_PAGE_SHIFT); > > pci_disable_ats(pdev); > > because the spec says the E field must change from Clear to Set to > cause invalidation of all ATC entries, so it's important to see that > we clear E first, then set it. Great, will correct. Thanks, Ethan > >> + */ >> + pci_enable_ats(pdev, VTD_PAGE_SHIFT); >> pci_disable_ats(pdev); >> info->ats_enabled = 0; >> domain_update_iotlb(info->domain); >> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c >> index 108158e2b907..5f13e017a12c 100644 >> --- a/drivers/iommu/intel/pasid.c >> +++ b/drivers/iommu/intel/pasid.c >> @@ -215,6 +215,13 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, >> return; >> >> sid = info->bus << 8 | info->devfn; >> + /* >> + * If device has been released from rbtree, no need to send ATS >> + * Invalidation request anymore, that could cause ITE fault. >> + */ >> + if (!device_rbtree_find(iommu, sid)) >> + return; >> + >> qdep = info->ats_qdep; >> pfsid = info->pfsid; >> >> -- >> 2.31.1 >>
On 2/29/2024 11:31 AM, Ethan Zhao wrote: > The introduction of per iommu device rbtree also defines the lifetime of > interoperation between iommu and devices, if the device has been released > from device rbtree, no need to send ATS invalidation request to it anymore, > thus avoid the possibility of later ITE fault to be triggered. > > This is part of the followup of prior proposed patchset > > https://do-db2.lkml.org/lkml/2024/2/22/350 > > To make sure all the devTLB entries to be invalidated in the device release > path, do implict invalidation by fapping the E bit of ATS control register. > see PCIe spec v6.2, sec 10.3.7 implicit invalidation events. > > Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") > Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> > --- > drivers/iommu/intel/iommu.c | 6 ++++++ > drivers/iommu/intel/pasid.c | 7 +++++++ > 2 files changed, 13 insertions(+) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 6743fe6c7a36..b85d88ccb4b0 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -1368,6 +1368,12 @@ static void iommu_disable_pci_caps(struct device_domain_info *info) > pdev = to_pci_dev(info->dev); > > if (info->ats_enabled) { > + pci_disable_ats(pdev); > + /* > + * flap the E bit of ATS control register to do implicit > + * ATS invlidation, see PCIe spec v6.2, sec 10.3.7 > + */ > + pci_enable_ats(pdev, VTD_PAGE_SHIFT); > pci_disable_ats(pdev); > info->ats_enabled = 0; > domain_update_iotlb(info->domain); > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c > index 108158e2b907..5f13e017a12c 100644 > --- a/drivers/iommu/intel/pasid.c > +++ b/drivers/iommu/intel/pasid.c > @@ -215,6 +215,13 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, > return; > > sid = info->bus << 8 | info->devfn; > + /* > + * If device has been released from rbtree, no need to send ATS > + * Invalidation request anymore, that could cause ITE fault. > + */ > + if (!device_rbtree_find(iommu, sid)) > + return; > + > qdep = info->ats_qdep; > pfsid = info->pfsid; > Given maintainer is going to pick up patchset https://lore.kernel.org/lkml/2d1788da-521c-4531-a159-81d2fb801d6c@linux.intel.com/T/ and this one is mutually exclusive with it, suspend. Thanks, Ethan
On Fri, Mar 01, 2024 at 09:50:36AM +0800, Ethan Zhao wrote: > On 3/1/2024 5:06 AM, Bjorn Helgaas wrote: > > On Wed, Feb 28, 2024 at 10:31:38PM -0500, Ethan Zhao wrote: > > > The introduction of per iommu device rbtree also defines the lifetime of > > > interoperation between iommu and devices, if the device has been released > > > from device rbtree, no need to send ATS invalidation request to it anymore, > > > thus avoid the possibility of later ITE fault to be triggered. > > > > > > This is part of the followup of prior proposed patchset > > > > > > https://do-db2.lkml.org/lkml/2024/2/22/350 > > Please use https://lore.kernel.org/ URLs instead. This one looks like > > https://lore.kernel.org/r/20240222090251.2849702-1-haifeng.zhao@linux.intel.com/ > > > > > To make sure all the devTLB entries to be invalidated in the device release > > > path, do implict invalidation by fapping the E bit of ATS control register. > > > see PCIe spec v6.2, sec 10.3.7 implicit invalidation events. > > s/implict/implicit/ > > > > s/fapping/?/ (no idea :) "flipping"? Oh, probably "flapping" per the > > comment below. But I think "flapping" is ambiguous; "setting" would be > > better) > > Yup, like the memory bit flipping, no idea what is the right word, > setting one bit to 0, then 1, then back to 0. perhaps details the > setting action 0-->1-->0 ? In PCIe spec-speak, "Set" means "assign 1 to this", and "Clear" means "assign 0 to this". Maybe you could copy the spec language like this: Invalidate all ATC entries by changing the E field in the ATS Capability from Clear to Set, which causes an implicit invalidation event. Bjorn
On 3/2/2024 5:56 AM, Bjorn Helgaas wrote: > On Fri, Mar 01, 2024 at 09:50:36AM +0800, Ethan Zhao wrote: >> On 3/1/2024 5:06 AM, Bjorn Helgaas wrote: >>> On Wed, Feb 28, 2024 at 10:31:38PM -0500, Ethan Zhao wrote: >>>> The introduction of per iommu device rbtree also defines the lifetime of >>>> interoperation between iommu and devices, if the device has been released >>>> from device rbtree, no need to send ATS invalidation request to it anymore, >>>> thus avoid the possibility of later ITE fault to be triggered. >>>> >>>> This is part of the followup of prior proposed patchset >>>> >>>> https://do-db2.lkml.org/lkml/2024/2/22/350 >>> Please use https://lore.kernel.org/ URLs instead. This one looks like >>> https://lore.kernel.org/r/20240222090251.2849702-1-haifeng.zhao@linux.intel.com/ >>> >>>> To make sure all the devTLB entries to be invalidated in the device release >>>> path, do implict invalidation by fapping the E bit of ATS control register. >>>> see PCIe spec v6.2, sec 10.3.7 implicit invalidation events. >>> s/implict/implicit/ >>> >>> s/fapping/?/ (no idea :) "flipping"? Oh, probably "flapping" per the >>> comment below. But I think "flapping" is ambiguous; "setting" would be >>> better) >> Yup, like the memory bit flipping, no idea what is the right word, >> setting one bit to 0, then 1, then back to 0. perhaps details the >> setting action 0-->1-->0 ? > In PCIe spec-speak, "Set" means "assign 1 to this", and "Clear" means > "assign 0 to this". > > Maybe you could copy the spec language like this: > > Invalidate all ATC entries by changing the E field in the ATS > Capability from Clear to Set, which causes an implicit invalidation > event. Fair enough. Thanks, Ethan > > Bjorn >
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 6743fe6c7a36..b85d88ccb4b0 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1368,6 +1368,12 @@ static void iommu_disable_pci_caps(struct device_domain_info *info) pdev = to_pci_dev(info->dev); if (info->ats_enabled) { + pci_disable_ats(pdev); + /* + * flap the E bit of ATS control register to do implicit + * ATS invlidation, see PCIe spec v6.2, sec 10.3.7 + */ + pci_enable_ats(pdev, VTD_PAGE_SHIFT); pci_disable_ats(pdev); info->ats_enabled = 0; domain_update_iotlb(info->domain); diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 108158e2b907..5f13e017a12c 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -215,6 +215,13 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iommu, return; sid = info->bus << 8 | info->devfn; + /* + * If device has been released from rbtree, no need to send ATS + * Invalidation request anymore, that could cause ITE fault. + */ + if (!device_rbtree_find(iommu, sid)) + return; + qdep = info->ats_qdep; pfsid = info->pfsid;