From nobody Tue Dec 2 00:02:27 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 AC9EE2F12A0; Tue, 25 Nov 2025 10:20:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066024; cv=none; b=nCJVMZTyv1cx8UeDS4r+tyBNYuP8qutzo6H+TX9j3OwNhS2bUYerSEWJa/fQO9QYP7OZA2VZsHArnRV0fK/q+S75likqQvESHSKWQK7hsyKGf79ZWrJcD6LF2We92Y1T6OqAURWevfOaafI1ikttIbccCRtDxvDsyLR7cfhfL18= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066024; c=relaxed/simple; bh=x3slilJPOuVDJRgPLoVKPtNTkD6lVokT73EPS5OWpEY=; h=Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type:Date; b=ILfQ/mClHVS+ocusK9sLiqI2HbOInu2uBrLBepschfTSlg14cxDjsvZecC9FfNqGyql/MxQFXxCCJ1Q1DF4ZPf5sqNF4L1dfwJ1BFUG4xCjgi4S0RyxkigUGh/NVvm/PiKGP6dfAUlkNelX7KNiYjb8pu/BZAcaLv/i3r1ISxyE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=bYE8U+9H; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=yyppOwmR; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="bYE8U+9H"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="yyppOwmR" Message-ID: <20251125102000.636453530@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1764066021; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=nh0WTmzh0DJjl8VxDftc+Gorf1cXtubgMwnD3nIZeIw=; b=bYE8U+9HZBALD6MMMmpzFs60HqShnU4+QSC3YHeR+sPeVNCq/VLkA1gBW4gVazTGww4Ti9 pSHQh4ODQ1uC+OPc9tgAooZy7EU9Fua7oFcmiz16nsOJ6jb3LqBxn0NTo4F3oKe+B3z3Gx M2D/6svlB/Y6wzZCrQiFVnHraXgWwrGUe7R+veW4bjNui1jRg8K9wp3ljq+eFHOMXvb59/ XSnfB4YM2gh4tepz30HycNCQ9pCCdcP4I6xAJ2mbUt5t9XZh9MnpwNebmtFuy3SXkJxav4 +fGxdgVoV2r1FPqmwU+m75nzuaomWkvoWzaVrit72zR05x9BDqoNKjrEDLdxRg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1764066021; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=nh0WTmzh0DJjl8VxDftc+Gorf1cXtubgMwnD3nIZeIw=; b=yyppOwmRltVprVroZ7Wy77ea/km9vDqML4zXQx1TYxktS7zuATaSrgTVvxz6WZAL3v7bd5 6CpHg1vPI1/+S6DA== From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Luigi Rizzo , stable@vger.kernel.org, Lu Baolu , Joerg Roedel Subject: [patch 1/3] x86/msi: Make irq_retrigger() functional for posted MSI References: <20251125101912.564125647@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Tue, 25 Nov 2025 11:20:20 +0100 (CET) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Luigi reported that retriggering a posted MSI interrupt does not work correctly. The reason is that the retrigger happens at the vector domain by sending an IPI to the actual vector on the target CPU. That works correctly exactly once because the posted MSI interrupt chip does not issue an EOI as that's only required for the posted MSI notification vector itself. As a consequence the vector becomes stale in the ISR, which not only affects this vector but also any lower priority vector in the affected APIC because the ISR bit is not cleared. Luigi proposed to set the vector in the remap PIR bitmap and raise the posted MSI notification vector. That works, but that still does not cure a related problem: If there is ever a stray interrupt on such a vector, then the related APIC ISR bit becomes stale due to the lack of EOI as described above. Unlikely to happen, but if it happens it's not debuggable at all. So instead of playing games with the PIR, this can be actually solved for both cases by: 1) Keeping track of the posted interrupt vector handler state 2) Implementing a posted MSI specific irq_ack() callback which checks that state. If the posted vector handler is inactive it issues an EOI, otherwise it delegates that to the posted handler. This is correct versus affinity changes and concurrent events on the posted vector as the actual handler invocation is serialized through the interrupt descriptor lock. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Reported-by: Luigi Rizzo Signed-off-by: Thomas Gleixner Tested-by: Luigi Rizzo Cc: stable@vger.kernel.org Closes: https://lore.kernel.org/lkml/20251124104836.3685533-1-lrizzo@google= .com --- arch/x86/include/asm/irq_remapping.h | 7 +++++++ arch/x86/kernel/irq.c | 23 +++++++++++++++++++++++ drivers/iommu/intel/irq_remapping.c | 8 ++++---- 3 files changed, 34 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/irq_remapping.h +++ b/arch/x86/include/asm/irq_remapping.h @@ -87,4 +87,11 @@ static inline void panic_if_irq_remap(co } =20 #endif /* CONFIG_IRQ_REMAP */ + +#ifdef CONFIG_X86_POSTED_MSI +void intel_ack_posted_msi_irq(struct irq_data *irqd); +#else +#define intel_ack_posted_msi_irq NULL +#endif + #endif /* __X86_IRQ_REMAPPING_H */ --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -397,6 +397,7 @@ DEFINE_IDTENTRY_SYSVEC_SIMPLE(sysvec_kvm =20 /* Posted Interrupt Descriptors for coalesced MSIs to be posted */ DEFINE_PER_CPU_ALIGNED(struct pi_desc, posted_msi_pi_desc); +static DEFINE_PER_CPU_CACHE_HOT(bool, posted_msi_handler_active); =20 void intel_posted_msi_init(void) { @@ -414,6 +415,25 @@ void intel_posted_msi_init(void) this_cpu_write(posted_msi_pi_desc.ndst, destination); } =20 +void intel_ack_posted_msi_irq(struct irq_data *irqd) +{ + irq_move_irq(irqd); + + /* + * Handle the rare case that irq_retrigger() raised the actual + * assigned vector on the target CPU, which means that it was not + * invoked via the posted MSI handler below. In that case APIC EOI + * is required as otherwise the ISR entry becomes stale and lower + * priority interrupts are never going to be delivered after that. + * + * If the posted handler invoked the device interrupt handler then + * the EOI would be premature because it would acknowledge the + * posted vector. + */ + if (unlikely(!this_cpu_read(posted_msi_handler_active))) + apic_eoi(); +} + static __always_inline bool handle_pending_pir(unsigned long *pir, struct = pt_regs *regs) { unsigned long pir_copy[NR_PIR_WORDS]; @@ -446,6 +466,8 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_posted_msi =20 pid =3D this_cpu_ptr(&posted_msi_pi_desc); =20 + /* Mark the handler active for intel_ack_posted_msi_irq() */ + this_cpu_write(posted_msi_handler_active, true); inc_irq_stat(posted_msi_notification_count); irq_enter(); =20 @@ -474,6 +496,7 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_posted_msi =20 apic_eoi(); irq_exit(); + this_cpu_write(posted_msi_handler_active, false); set_irq_regs(old_regs); } #endif /* X86_POSTED_MSI */ --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -1303,17 +1303,17 @@ static struct irq_chip intel_ir_chip =3D { * irq_enter(); * handle_edge_irq() * irq_chip_ack_parent() - * irq_move_irq(); // No EOI + * intel_ack_posted_msi_irq(); // No EOI * handle_irq_event() * driver_handler() * handle_edge_irq() * irq_chip_ack_parent() - * irq_move_irq(); // No EOI + * intel_ack_posted_msi_irq(); // No EOI * handle_irq_event() * driver_handler() * handle_edge_irq() * irq_chip_ack_parent() - * irq_move_irq(); // No EOI + * intel_ack_posted_msi_irq(); // No EOI * handle_irq_event() * driver_handler() * apic_eoi() @@ -1322,7 +1322,7 @@ static struct irq_chip intel_ir_chip =3D { */ static struct irq_chip intel_ir_chip_post_msi =3D { .name =3D "INTEL-IR-POST", - .irq_ack =3D irq_move_irq, + .irq_ack =3D intel_ack_posted_msi_irq, .irq_set_affinity =3D intel_ir_set_affinity, .irq_compose_msi_msg =3D intel_ir_compose_msi_msg, .irq_set_vcpu_affinity =3D intel_ir_set_vcpu_affinity, From nobody Tue Dec 2 00:02:27 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 946BB2F12BD for ; Tue, 25 Nov 2025 10:20:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066027; cv=none; b=qgfnBfuLwTW9zpoEis/PYK5qtnAsJHF+LZ6UqfuGk0UnZ4+sVIKGRri+eGDdEo0VaNcheFs91x1cy5qN3hteWpXOgG5xn4l51odv3BVDzWlwAlg7hEZQyTr7EMjqUWcgSGUe9/Vzi5mv9XyxSkWvD7EZD9BC9tljLQKZMuSY09o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066027; c=relaxed/simple; bh=ThULgGE5HtqxkienEmg1LbApJ1gx0cXbI3YA4yF4y4k=; h=Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type:Date; b=Cm47/TtTF3+eCuVOzNdiM+kDsZqKvrP2lbStT/+cGPKeII925RSY7iC3Cae7dqSs09xss+PXmWlgwOZ02owv2m3EbfAErnY0vV8Y94ICsNheNI40XCJ1YCqGaavMGop66pas1Ir2If+fVkuPeWjynoIjZ0LmN3yNKI0lR5eJecc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=0dCzXaow; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zMw7XbJH; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="0dCzXaow"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zMw7XbJH" Message-ID: <20251125102000.699735132@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1764066023; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=czOKra+JElCo18rWCOg9NtKsN1jpBWlwRqImLdg5HVg=; b=0dCzXaowik80+pISltCCEztQGGlx6eYEuBPtzhSNkrbEGoAAffpje6DH6irDjwWM5jey14 YRIDH/TVRedlGhOF2L+tMrJzCY1wJNzRb5Hk+DYGnrA4we8W0/I9A5T5UFqEtA2qkhdfX7 pZ5bFW6RfNoAbUuD0132jPAu9qQ3A/ULQDawIlzUPyOQI4ml/42ImYBVszMUIFXZYGC7Di dCetLBYQ2LwXSVubKKldF62lDp00nEuw7LLisp7nU82TKLEijzkgGIEcve97ua+4okrAno ImdESYhHou96Y86DZuEoglD/DwHaH6sO5ISPYuTOFENIN1LG5n6/togZtDnf4Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1764066023; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=czOKra+JElCo18rWCOg9NtKsN1jpBWlwRqImLdg5HVg=; b=zMw7XbJHPhAgJCq8XpZyfaghwqdl3T3avx1nJ1Q8dtxGKpRbDu4o4/OuPHZO26ab1A2mWR LHnpQAxC4MxvVqCQ== From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Luigi Rizzo , Lu Baolu , Joerg Roedel Subject: [patch 2/3] x86/irq: Cleanup posted MSI code References: <20251125101912.564125647@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Tue, 25 Nov 2025 11:20:22 +0100 (CET) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Make code and comments readable. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/irq.c | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) --- a/arch/x86/kernel/irq.c +++ b/arch/x86/kernel/irq.c @@ -401,11 +401,9 @@ static DEFINE_PER_CPU_CACHE_HOT(bool, po =20 void intel_posted_msi_init(void) { - u32 destination; - u32 apic_id; + u32 destination, apic_id; =20 this_cpu_write(posted_msi_pi_desc.nv, POSTED_MSI_NOTIFICATION_VECTOR); - /* * APIC destination ID is stored in bit 8:15 while in XAPIC mode. * VT-d spec. CH 9.11 @@ -449,8 +447,8 @@ static __always_inline bool handle_pendi } =20 /* - * Performance data shows that 3 is good enough to harvest 90+% of the ben= efit - * on high IRQ rate workload. + * Performance data shows that 3 is good enough to harvest 90+% of the + * benefit on high interrupt rate workloads. */ #define MAX_POSTED_MSI_COALESCING_LOOP 3 =20 @@ -460,11 +458,8 @@ static __always_inline bool handle_pendi */ DEFINE_IDTENTRY_SYSVEC(sysvec_posted_msi_notification) { + struct pi_desc *pid =3D this_cpu_ptr(&posted_msi_pi_desc); struct pt_regs *old_regs =3D set_irq_regs(regs); - struct pi_desc *pid; - int i =3D 0; - - pid =3D this_cpu_ptr(&posted_msi_pi_desc); =20 /* Mark the handler active for intel_ack_posted_msi_irq() */ this_cpu_write(posted_msi_handler_active, true); @@ -472,25 +467,25 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_posted_msi irq_enter(); =20 /* - * Max coalescing count includes the extra round of handle_pending_pir - * after clearing the outstanding notification bit. Hence, at most - * MAX_POSTED_MSI_COALESCING_LOOP - 1 loops are executed here. + * Loop only MAX_POSTED_MSI_COALESCING_LOOP - 1 times here to take + * the final handle_pending_pir() invocation after clearing the + * outstanding notification bit into account. */ - while (++i < MAX_POSTED_MSI_COALESCING_LOOP) { + for (int i =3D 1; i < MAX_POSTED_MSI_COALESCING_LOOP; i++) { if (!handle_pending_pir(pid->pir, regs)) break; } =20 /* - * Clear outstanding notification bit to allow new IRQ notifications, - * do this last to maximize the window of interrupt coalescing. + * Clear the outstanding notification bit to rearm the notification + * mechanism. */ pi_clear_on(pid); =20 /* - * There could be a race of PI notification and the clearing of ON bit, - * process PIR bits one last time such that handling the new interrupts - * are not delayed until the next IRQ. + * Clearing the ON bit can race with a notification. Process the + * PIR bits one last time so that handling the new interrupts is + * not delayed until the next notification happens. */ handle_pending_pir(pid->pir, regs); From nobody Tue Dec 2 00:02:27 2025 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 EE96025A2DE for ; Tue, 25 Nov 2025 10:20:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066029; cv=none; b=i4bSsJEp+LLrpDsVX/2LC+dwDxmX4ViaLxxrkJZpmgldg478ZaRv8eUQZaG7w2C2BlhJvxOFQ6L2uxRng4V6DzTp5lOaH0eB34gw76pNS7EsWuFXIdzDkj0VBPb8qvJFD3XKIAdj9s1Uh78Z9UjETXmjkBsyac8+L4JZiG40jCU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764066029; c=relaxed/simple; bh=FX6vQCjspxWdfPC/pP/DPZ4hXHIGjzfMuhEKO1y22j8=; h=Message-ID:From:To:Cc:Subject:References:MIME-Version: Content-Type:Date; b=rRdNSgGz/Jl4jJMuRvlDRGKsBau2mdMlB4f25JHtDtqcjvtcM+6yVqQ0dY0hJ9UG3TPYvlrm4aG2irVv7jhtY+YtHX/SW8vYHAKoROw5XXaCqhTYUgQPlLGYF2bwnazIuFcvptwL43VqBe7heLkMXDYiCJIO5fvOW5H1lPGkbN0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=pFfvr8Qw; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=nSZ006Vu; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="pFfvr8Qw"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="nSZ006Vu" Message-ID: <20251125102000.763427030@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1764066026; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=CKOcxgwQC9pKv1DGXKe9DExfiqkuy6yibuRoUUEeNOQ=; b=pFfvr8QwCH6DX15Fk58bKeQ3FM6OVGnzio90AJ1j40CqtlQAsSorMGN0gduywYKrzhezC3 W10eQxf0L6h9lqb/6IOq1wwbKWzvQ3WQCtu7h1R16KVjObi9yktb8D/hiy9vHmN8KaWlQC uIv5srMJs5i1FQO29JrS8cXJRt4ZH53nsTqR/4Kl3amkCeZYXodyH0n4y/2akk7WdF2R4C eCFtVJnYYwGNPoRCKynWERRileok4ucZnBB5EEKpU1gj7vlRu5zXcG6TI9NQQqGVpVWBAL ey4o7aCV6tk4NzCS1CVDZyO6+b6J+vfvVx/+4dUzdpiS2hXAJg7Tpvzj5jnykw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1764066026; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=CKOcxgwQC9pKv1DGXKe9DExfiqkuy6yibuRoUUEeNOQ=; b=nSZ006Vu5NMbvPlJgPWvdTRN3FcLxreUVGbtPQuARRtKyTaSngkXqkSADrsggRhHfOkkRL KOMKxu00AGQukOBQ== From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Lu Baolu , Joerg Roedel , Luigi Rizzo Subject: [patch 3/3] x86/irq_remapping: Sanitize posted_msi_supported() References: <20251125101912.564125647@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Tue, 25 Nov 2025 11:20:25 +0100 (CET) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" posted_msi_supported() is a misnomer as it actually checks whether it is enabled or not. Aside of that this does not take CONFIG_X86_POSTED_MSI into account which is required to actually use it. Rename it to posted_msi_enabled() and make the return value depend on CONFIG_X86_POSTED_MSI, which allows the compiler to eliminate the related dead code and data if disabled: text data bss dec hex filename 10046 701 3296 14043 36db drivers/iommu/intel/irq_remapping.o 9904 413 3296 13613 352d drivers/iommu/intel/irq_remapping.o Signed-off-by: Thomas Gleixner Cc: Lu Baolu Cc: Joerg Roedel --- arch/x86/include/asm/irq_remapping.h | 5 +++-- drivers/iommu/intel/irq_remapping.c | 4 ++-- 2 files changed, 5 insertions(+), 4 deletions(-) --- a/arch/x86/include/asm/irq_remapping.h +++ b/arch/x86/include/asm/irq_remapping.h @@ -67,9 +67,10 @@ static inline struct irq_domain *arch_ge =20 extern bool enable_posted_msi; =20 -static inline bool posted_msi_supported(void) +static inline bool posted_msi_enabled(void) { - return enable_posted_msi && irq_remapping_cap(IRQ_POSTING_CAP); + return IS_ENABLED(CONFIG_X86_POSTED_MSI) && + enable_posted_msi && irq_remapping_cap(IRQ_POSTING_CAP); } =20 #else /* CONFIG_IRQ_REMAP */ --- a/drivers/iommu/intel/irq_remapping.c +++ b/drivers/iommu/intel/irq_remapping.c @@ -1368,7 +1368,7 @@ static void intel_irq_remapping_prepare_ break; case X86_IRQ_ALLOC_TYPE_PCI_MSI: case X86_IRQ_ALLOC_TYPE_PCI_MSIX: - if (posted_msi_supported()) { + if (posted_msi_enabled()) { prepare_irte_posted(irte); data->irq_2_iommu.posted_msi =3D 1; } @@ -1460,7 +1460,7 @@ static int intel_irq_remapping_alloc(str =20 irq_data->hwirq =3D (index << 16) + i; irq_data->chip_data =3D ird; - if (posted_msi_supported() && + if (posted_msi_enabled() && ((info->type =3D=3D X86_IRQ_ALLOC_TYPE_PCI_MSI) || (info->type =3D=3D X86_IRQ_ALLOC_TYPE_PCI_MSIX))) irq_data->chip =3D &intel_ir_chip_post_msi;