From nobody Sun Feb 8 08:46:07 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 A0BC560268; Fri, 26 Jan 2024 23:37:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706312251; cv=none; b=MIoMveoadXWzrlXR4IHD861Ucqet4jUn8PDfO4+u2rMdJgY3VdaMz5Dj9O49eB7U0OPGQqRP4KxO7zQBqnmIzUFYnzgVLpcMOGvnhX0qPIX+nRzSzqaPiPj3HqIRWCUbZgcv3DRCBjnuAxijhzftXIXXYzKLIvHGGP2NHo/ART4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706312251; c=relaxed/simple; bh=5z7HUBzE7Ul+Bci9YbfIrBXJxLaOXS9r2ggCh19e6Ag=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=hWslVEJxlPWavH7xH9pm6qax6ENH5Dhh4EklWS+nVzJos465Eug+aGuCotEXR5icnpisuCRc1laA+m9VuDcOQI1R8+6qjT0KJx5lG+t+HN7W30neztvC/jzMmjRnEKTvvohriF8qYD9ocR0yD9ads5k2VrmbY5ZAFmg0/HoRYng= 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=iaKSdoT7; arc=none smtp.client-ip=192.198.163.10 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="iaKSdoT7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706312250; x=1737848250; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5z7HUBzE7Ul+Bci9YbfIrBXJxLaOXS9r2ggCh19e6Ag=; b=iaKSdoT7f1BgjB9CyiKX5BC1FM6Up2YfHvVQNXGifwIO6UMS12E7P7Jr HAiHpFysaoD7/V/q0mcuopQwTu1A5yBQUesUBb4KW6kcFYhZYi/5OAJpv 3SCVJee/97y9xq5fiTlbp1pwtoAlyAoA17yzNCpE6los58/pcDlOP35Mh ljNwB1HLbhBBaVXBfwd07fpffXHlap3hWJaQ2xgZl4btRkrdBGTFYbXsP wknz0fFYRWGEM7cbBWz+y+5jJ8tjNgoX8Ugtdy2tmABrd+krvbfwy/ppt /E9gvtgzaSu5thLCnD/5MTd8O9Grj/+PqIIwBFuzHIdr7PjGZ5Ap6E7E7 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10964"; a="9990760" X-IronPort-AV: E=Sophos;i="6.05,220,1701158400"; d="scan'208";a="9990760" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jan 2024 15:37:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10964"; a="821290745" X-IronPort-AV: E=Sophos;i="6.05,220,1701158400"; d="scan'208";a="821290745" Received: from srinivas-otcpl-7600.jf.intel.com (HELO jacob-builder.jf.intel.com) ([10.54.39.116]) by orsmga001.jf.intel.com with ESMTP; 26 Jan 2024 15:37:22 -0800 From: Jacob Pan To: LKML , X86 Kernel , Peter Zijlstra , iommu@lists.linux.dev, Thomas Gleixner , "Lu Baolu" , kvm@vger.kernel.org, Dave Hansen , Joerg Roedel , "H. Peter Anvin" , "Borislav Petkov" , "Ingo Molnar" Cc: Paul Luse , Dan Williams , Jens Axboe , Raj Ashok , "Tian, Kevin" , maz@kernel.org, seanjc@google.com, "Robin Murphy" , Jacob Pan Subject: [PATCH 11/15] x86/irq: Extend checks for pending vectors to posted interrupts Date: Fri, 26 Jan 2024 15:42:33 -0800 Message-Id: <20240126234237.547278-12-jacob.jun.pan@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240126234237.547278-1-jacob.jun.pan@linux.intel.com> References: <20240126234237.547278-1-jacob.jun.pan@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" During interrupt affinity change, it is possible to have interrupts deliver= ed to the old CPU after the affinity has changed to the new one. To prevent lo= st interrupts, local APIC IRR is checked on the old CPU. Similar checks must be done for posted MSIs given the same reason. Consider the following scenario: Device system agent iommu memory CPU/LAPIC 1 FEEX_XXXX 2 Interrupt request 3 Fetch IRTE -> 4 ->Atomic Swap PID.PIR(vec) Push to Global Observable(GO) 5 if (ON*) i done;* else 6 send a notification -> * ON: outstanding notification, 1 will suppress new notifications If the affinity change happens between 3 and 5 in IOMMU, the old CPU's post= ed interrupt request (PIR) could have pending bit set for the vector being mov= ed. Signed-off-by: Jacob Pan --- arch/x86/include/asm/apic.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h index e9d8e554765c..6661fefdd49a 100644 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@ -13,6 +13,7 @@ #include #include #include +#include =20 #define ARCH_APICTIMER_STOPS_ON_C3 1 =20 @@ -500,7 +501,7 @@ static inline bool is_vector_pending(unsigned int vecto= r) if (irr & (1 << (vector % 32))) return true; =20 - return false; + return pi_pending_this_cpu(vector); } =20 /* --=20 2.25.1