From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 C86F9371045 for ; Fri, 6 Mar 2026 07:08:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772780900; cv=none; b=m2oCuFbgoxKktsFCiBXBOnY0fWKhHYN/ZwgEtf4+6TiUF1Z5wa+hGu75ZYg1U/jJKJm6Brg7RCBq7XMwY0tFpCENryHcej4yHiZDYvYY81gFi8DvDw/7NdzyhcoTAFh/AfmMoxeT9xU55Jli98WKIq7/ZKZk7GEv3r+GSaaPd+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772780900; c=relaxed/simple; bh=HxM1onQZsv/gkHN3wcbVvGdFjHvqt3U5VT1vgAqejlg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oXQvyAe17YjNr3clLHNCvH1ZY8yppOXAoOeQGSHy9BFFjazsNv78+mqGOE4QfmS43fnM10zZf1jRtm3BCUZOi38qNCeNT3jazFwT01Oz5iiwbYqI1385TiXa/cahDxasujpEh77wfl9uQtnjE1SNNeORZWGjgHuaZGYQYwUqwAA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Vj7dvCIf; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Vj7dvCIf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772780898; x=1804316898; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=HxM1onQZsv/gkHN3wcbVvGdFjHvqt3U5VT1vgAqejlg=; b=Vj7dvCIft4M2kTp0Fkbtq2BZ2ADeZmziLNLySYPT979R+Zd5fJEYP6IE oFqf58egY9d1xMlHErtvh1H3i+glHXKVzumZyfCPu1NDzqo6rhxFNlI4L YWCf9Y3NbVa0aGjs200MxHAPaOgpy04+iVyBSQvaxt/e67P9ItVezY6vh AjaGg8EWmoxyp6clGDDt6zX9T8Ks6eRICYR62XqMxkp1RVUy4tUByxvIK rKHbqH1D6co9sLnrAdNQ8ae2uNiSbkucstZ7kdsdUtPGttSsXi09rsvCU UCJdkSYrlUnekosq41X4hNcoGE4xznlEahBNK3z2TcUKcwEHnoPF22H9o w==; X-CSE-ConnectionGUID: vaekWrt5QEOnTxfWO39iDA== X-CSE-MsgGUID: xtBzMGMJQAaEeCqqYFRShw== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="74001965" X-IronPort-AV: E=Sophos;i="6.23,104,1770624000"; d="scan'208";a="74001965" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 23:08:18 -0800 X-CSE-ConnectionGUID: H7prEQdMT2yPbZebkUG+PQ== X-CSE-MsgGUID: Mk3vzjpXTA++RW6+bC51BQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,104,1770624000"; d="scan'208";a="223889687" Received: from allen-sbox.sh.intel.com (HELO [10.239.159.30]) ([10.239.159.30]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 23:08:16 -0800 Message-ID: <3a4ba1bb-2c45-465a-b7f4-3b999f33b1a5@linux.intel.com> Date: Fri, 6 Mar 2026 15:07:34 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] iommu/vt-d: fix intel iommu iotlb sync hardlockup and retry To: Guanghui Feng , dwmw2@infradead.org, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org References: <20260209075953.2253094-1-guanghuifeng@linux.alibaba.com> Content-Language: en-US From: Baolu Lu In-Reply-To: <20260209075953.2253094-1-guanghuifeng@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/9/26 15:59, Guanghui Feng wrote: > Device-TLB Invalidation Response Time-out (ITE) handling was added in > commit: 6ba6c3a4cacf. > > When an ITE occurs, iommu will sets the ITE (Invalidation Time-out > Error) field in the Fault Status Register. No new descriptors are > fetched from the Invalidation Queue until software clears the ITE field > in the Fault Status Register. Tail pointer Register updates by software > while the ITE field is Set does not cause descriptor fetches by > hardware. At the time ITE field is Set, hardware aborts any > inv_wait_dsc commands pending in hardware and does not increment > the Invalidation Queue Head register. When software clears the > ITE field in the Fault Status Register, hardware fetches > descriptor pointed by the Invalidation Queue Head register. > > But in the qi_check_fault process, it is implemented by default > according to the 2009 commit: 6ba6c3a4cacf, that is, only one > struct qi_desc is submitted at a time. A qi_desc request is > immediately followed by a wait_desc/QI_IWD_TYPE for > synchronization. Therefore, the IOMMU driver implementation > considers invalid queue entries at odd positions to be > wait_desc. After ITE is set, hardware aborts any pending > inv_wait_dsc commands in hardware. Therefore, qi_check_fault > iterates through odd-position as wait_desc entries and sets > desc_status to QI_ABORT. However, the current implementation > allows multiple struct qi_desc to be submitted simultaneously, > followed by one wait_desc, so it's no longer guaranteed that > odd-position entries will be wait_desc. When the number of submitted > struct qi_desc is even, wait_desc's desc_status will not be set to QI_ABORT, > qi_check_fault will return 0, and qi_submit_sync will then > execute in an infinite loop and cause a hard lockup when > interrupts are disabled and the PCIe device does not respond to > Device-TLB Invalidation requests. --- > Additionally, if the device remains online and an IOMMU ITE > occurs, simply returning -EAGAIN is sufficient. When processing > the -EAGAIN result, qi_submit_sync will automatically reclaim > all submitted struct qi_desc and resubmit the requests. > > Through this modification: > 1. Correctly triggers the resubmission of struct qi_desc when > an ITE occurs. > 2. Prevents the IOMMU driver from disabling interrupts and > executing in an infinite loop within qi_submit_sync when an > 3. Correctly handling simultaneous requests from multiple CPUs > and multiple contexts that result in timeouts. --- The two paragraphs above don't match the code. Would you mind cleaning them up? > > Signed-off-by: Guanghui Feng Fixes: 8a1d82462540 ("iommu/vt-d: Multiple descriptors per qi_submit_sync()") Cc: stable@vger.kernel.org > --- > drivers/iommu/intel/dmar.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index ec975c73cfe6..6938800e9884 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -1314,7 +1314,6 @@ static int qi_check_fault(struct intel_iommu *iommu, int index, int wait_index) > if (fault & DMA_FSTS_ITE) { > head = readl(iommu->reg + DMAR_IQH_REG); > head = ((head >> shift) - 1 + QI_LENGTH) % QI_LENGTH; > - head |= 1; > tail = readl(iommu->reg + DMAR_IQT_REG); > tail = ((tail >> shift) - 1 + QI_LENGTH) % QI_LENGTH; > > @@ -1331,7 +1330,7 @@ static int qi_check_fault(struct intel_iommu *iommu, int index, int wait_index) > do { > if (qi->desc_status[head] == QI_IN_USE) > qi->desc_status[head] = QI_ABORT; > - head = (head - 2 + QI_LENGTH) % QI_LENGTH; > + head = (head - 1 + QI_LENGTH) % QI_LENGTH; > } while (head != tail); > > /* The code itself looks good to me. Thanks, baolu