[RFC,v8,5/5] iommu/vt-d: don't loop for timeout device-TLB invalidation request forever
Message ID | 20231227025923.536148-6-haifeng.zhao@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-11790-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp1215454dyb; Tue, 26 Dec 2023 19:02:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IF70QQRY+hBs3fWkucuv0F7mJ5ypjNj7M5o8ZUH3KTtYSRrEqvULPeL4DntJZLt8a029vdw X-Received: by 2002:a17:90b:ed3:b0:28b:b974:327 with SMTP id gz19-20020a17090b0ed300b0028bb9740327mr3776602pjb.86.1703646139807; Tue, 26 Dec 2023 19:02:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703646139; cv=none; d=google.com; s=arc-20160816; b=n4awd/Zo4WFlmXaXyc0OanmBzCJsL4wDvoQjxLErO3ADdaQq+9u7f3iyNHnxGfjyln olhx/J1ZXTfCw0/i72pYi4+9bjnbh1T97miKdIgLMhjRdP2O77oWI2uuVIJWF/t9lQH9 2rmAoJkbONYIBjZ75aTNt+JeaHgcL/Ab0kIS8cT8mixtd+FpsF71GRzNAjXE745cAXvU u5ymwsjevroWVk4/vLkx2jox64NO0Ly4v/Fe0qldxCRwthIgRoOT49kYXncyj62IC5pI vq9Zw+VBmXAxXA+oUmN3A/c6yWZ5nZgQxhOvCkqMni5gjFaGYTQXVP/O7+1XYOGUCLBf DHHw== ARC-Message-Signature: i=1; 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:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=sbE7YGLTW4UjkKn4d+DaEtg1acYJj+hqWZwxXHrq+jE=; fh=cQTxynQ7rGExgmbyXq8tNmd/VmE1Fzgt9QW51hABj2c=; b=HfD3hq/FoDfVzUpYNlKVbL0QxnlqtfnPUxTqpugc2Yq4ps8yTk9hYi2Oe4co74oVt6 5HCheYBG27bhjWepKgwJHNJkZ3BSMmbUNtaCLF2iXMJBJS0rkds8Hdw/sZyCkEp5trhy 7ukB6gSLicFH+W2Wkc6ImSd7KEwjieLs1ffiszxbJOIGA4ADsy3lX7YWS6zxZiRCd0OV 1thbSKfOw8t+03RZor4PIj5x1S94v3+lYH7owYtsiIv38Vx8UQ0G66gurLjEI8HGn5o9 nhI8wTjwyxjmJyiZkbxxdIgQY1aSFgEi6Omvh3wqJRhjrWkJqJ5zqBxp3UuDvz0PIaFd npbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jsYNCPOh; spf=pass (google.com: domain of linux-kernel+bounces-11790-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11790-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id b11-20020a17090a9bcb00b0028c25f30c9csi7098324pjw.141.2023.12.26.19.02.19 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Dec 2023 19:02:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-11790-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jsYNCPOh; spf=pass (google.com: domain of linux-kernel+bounces-11790-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11790-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 6D9F8B224D1 for <ouuuleilei@gmail.com>; Wed, 27 Dec 2023 03:01:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9F9106FC9; Wed, 27 Dec 2023 02:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jsYNCPOh" X-Original-To: linux-kernel@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 A891B3C2C; Wed, 27 Dec 2023 02:59:48 +0000 (UTC) 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=1703645989; x=1735181989; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ADwcXlRKPSNfjDAnN/YVM4hrSWE49DUML8+gC/Dr3BI=; b=jsYNCPOhi/jUGCF0keJYJC7op0yQ9JrfpIdppxFjs+u24JvJuGcEnocr kJIRDSxu1gE+DBMYKY+2KEs3n1G5155SKm01pxoNRDsnNj8TCXa4aak+6 eMk9WQee5MBpXYC0Dl8pfkcQktdlaHFmv3wHpk7wJBRIa6E6jqmIZlQ+P 7WzXNpvnIWhil4n5bxdM2GMC/CXKJPjY+VhelmjAwUD0lsfOUTU1aQyCo dFDJmq+0q6288KlDJwvi9liLWG9dr/+LnKSHLyKkhXvR9nzDe+76JLGJ/ 9MLeY+hGEHnvgOYjUQCuN6NjUT2kBLjqEDoTjVGYV8DVDWnL1dY1efFuZ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10935"; a="3705836" X-IronPort-AV: E=Sophos;i="6.04,307,1695711600"; d="scan'208";a="3705836" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Dec 2023 18:59:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10935"; a="951386103" X-IronPort-AV: E=Sophos;i="6.04,307,1695711600"; d="scan'208";a="951386103" Received: from ply01-vm-store.bj.intel.com ([10.238.153.201]) by orsmga005.jf.intel.com with ESMTP; 26 Dec 2023 18:59:40 -0800 From: Ethan Zhao <haifeng.zhao@linux.intel.com> To: bhelgaas@google.com, baolu.lu@linux.intel.com, dwmw2@infradead.org, will@kernel.org, robin.murphy@arm.com, lukas@wunner.de Cc: linux-pci@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [RFC PATCH v8 5/5] iommu/vt-d: don't loop for timeout device-TLB invalidation request forever Date: Tue, 26 Dec 2023 21:59:23 -0500 Message-Id: <20231227025923.536148-6-haifeng.zhao@linux.intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20231227025923.536148-1-haifeng.zhao@linux.intel.com> References: <20231227025923.536148-1-haifeng.zhao@linux.intel.com> 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: 1786402454686839059 X-GMAIL-MSGID: 1786402454686839059 |
Series |
fix vt-d hard lockup when hotplug ATS capable device
|
|
Commit Message
Ethan Zhao
Dec. 27, 2023, 2:59 a.m. UTC
When the device-TLB invalidation (ATS invalidation) timeout happens, the
qi_submit_sync() will restart and loop for the invalidation request
forever till it is done, it will block another invalidation thread such
as the fq_timer to issue invalidation request, cause the system lockup as
following
[exception RIP: native_queued_spin_lock_slowpath+92]
RIP: ffffffffa9d1025c RSP: ffffb202f268cdc8 RFLAGS: 00000002
RAX: 0000000000000101 RBX: ffffffffab36c2a0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffab36c2a0
RBP: ffffffffab36c2a0 R8: 0000000000000001 R9: 0000000000000000
R10: 0000000000000010 R11: 0000000000000018 R12: 0000000000000000
R13: 0000000000000004 R14: ffff9e10d71b1c88 R15: ffff9e10d71b1980
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- ---
(the left part of exception see the hotplug case of ATS capable device)
If one endpoint device just no response to the device-TLB invalidation
request, but is not gone, it will bring down the whole system, to avoid
such case, don't try the timeout device-TLB request forever.
and as synchronous program model of current qi_submit_sync() implementation
we couldn't wait for the enough time as PCIe spec said 1min+50%, just break
it in current sync model. (PCIe spec r6.1, sec 10.3.1)
Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com>
---
drivers/iommu/intel/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 12/27/2023 10:59 AM, Ethan Zhao wrote: > When the device-TLB invalidation (ATS invalidation) timeout happens, the > qi_submit_sync() will restart and loop for the invalidation request > forever till it is done, it will block another invalidation thread such > as the fq_timer to issue invalidation request, cause the system lockup as > following > > [exception RIP: native_queued_spin_lock_slowpath+92] > > RIP: ffffffffa9d1025c RSP: ffffb202f268cdc8 RFLAGS: 00000002 > > RAX: 0000000000000101 RBX: ffffffffab36c2a0 RCX: 0000000000000000 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffab36c2a0 > > RBP: ffffffffab36c2a0 R8: 0000000000000001 R9: 0000000000000000 > > R10: 0000000000000010 R11: 0000000000000018 R12: 0000000000000000 > > R13: 0000000000000004 R14: ffff9e10d71b1c88 R15: ffff9e10d71b1980 > > ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- --- #12 [ffffb202f268cdc8] native_queued_spin_lock_slowpath at ffffffffa9d1025c #13 [ffffb202f268cdc8] do_raw_spin_lock at ffffffffa9d121f1 #14 [ffffb202f268cdd8] _raw_spin_lock_irqsave at ffffffffaa51795b #15 [ffffb202f268cdf8] iommu_flush_dev_iotlb at ffffffffaa20df48 #16 [ffffb202f268ce28] iommu_flush_iova at ffffffffaa20e182 #17 [ffffb202f268ce60] iova_domain_flush at ffffffffaa220e27 #18 [ffffb202f268ce70] fq_flush_timeout at ffffffffaa221c9d #19 [ffffb202f268cea8] call_timer_fn at ffffffffa9d46661 #20 [ffffb202f268cf08] run_timer_softirq at ffffffffa9d47933 #21 [ffffb202f268cf98] __softirqentry_text_start at ffffffffaa8000e0 #22 [ffffb202f268cff0] asm_call_sysvec_on_stack at ffffffffaa60114f > --- --- > > (the left part of exception see the hotplug case of ATS capable device) > > If one endpoint device just no response to the device-TLB invalidation > request, but is not gone, it will bring down the whole system, to avoid > such case, don't try the timeout device-TLB request forever. > > and as synchronous program model of current qi_submit_sync() implementation > we couldn't wait for the enough time as PCIe spec said 1min+50%, just break > it in current sync model. (PCIe spec r6.1, sec 10.3.1) > > Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> > --- > drivers/iommu/intel/dmar.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index 76903a8bf963..206ab0b7294f 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -1457,7 +1457,7 @@ int qi_submit_sync(struct intel_iommu *iommu, struct qi_desc *desc, > reclaim_free_desc(qi); > raw_spin_unlock_irqrestore(&qi->q_lock, flags); > > - if (rc == -EAGAIN) > + if (rc == -EAGAIN && type !=QI_DIOTLB_TYPE && type != QI_DEIOTLB_TYPE) > goto restart; > > if (iotlb_start_ktime)
On 12/27/2023 10:59 AM, Ethan Zhao wrote: > When the device-TLB invalidation (ATS invalidation) timeout happens, the > qi_submit_sync() will restart and loop for the invalidation request > forever till it is done, it will block another invalidation thread such > as the fq_timer to issue invalidation request, cause the system lockup as > following > > [exception RIP: native_queued_spin_lock_slowpath+92] > > RIP: ffffffffa9d1025c RSP: ffffb202f268cdc8 RFLAGS: 00000002 > > RAX: 0000000000000101 RBX: ffffffffab36c2a0 RCX: 0000000000000000 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffab36c2a0 > > RBP: ffffffffab36c2a0 R8: 0000000000000001 R9: 0000000000000000 > > R10: 0000000000000010 R11: 0000000000000018 R12: 0000000000000000 > > R13: 0000000000000004 R14: ffff9e10d71b1c88 R15: ffff9e10d71b1980 > > ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 Wrong past, please ignore this series. Thanks, Ethan > > --- --- > > (the left part of exception see the hotplug case of ATS capable device) > > If one endpoint device just no response to the device-TLB invalidation > request, but is not gone, it will bring down the whole system, to avoid > such case, don't try the timeout device-TLB request forever. > > and as synchronous program model of current qi_submit_sync() implementation > we couldn't wait for the enough time as PCIe spec said 1min+50%, just break > it in current sync model. (PCIe spec r6.1, sec 10.3.1) > > Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com> > --- > drivers/iommu/intel/dmar.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index 76903a8bf963..206ab0b7294f 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -1457,7 +1457,7 @@ int qi_submit_sync(struct intel_iommu *iommu, struct qi_desc *desc, > reclaim_free_desc(qi); > raw_spin_unlock_irqrestore(&qi->q_lock, flags); > > - if (rc == -EAGAIN) > + if (rc == -EAGAIN && type !=QI_DIOTLB_TYPE && type != QI_DEIOTLB_TYPE) > goto restart; > > if (iotlb_start_ktime)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 76903a8bf963..206ab0b7294f 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1457,7 +1457,7 @@ int qi_submit_sync(struct intel_iommu *iommu, struct qi_desc *desc, reclaim_free_desc(qi); raw_spin_unlock_irqrestore(&qi->q_lock, flags); - if (rc == -EAGAIN) + if (rc == -EAGAIN && type !=QI_DIOTLB_TYPE && type != QI_DEIOTLB_TYPE) goto restart; if (iotlb_start_ktime)