From: sashiko-bot@kernel.org
To: "Wanpeng Li" <kernellwp@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 08/10] KVM: x86/lapic: Clear IPI tracking on matching-vector EOI
Date: Fri, 12 Jun 2026 03:46:32 +0000 [thread overview]
Message-ID: <20260612034633.023F11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612013355.59231-9-kernellwp@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The EOI handler incorrectly clears the vCPU's outgoing IPI tracking state when acknowledging an incoming IPI due to conflated incoming and outgoing tracking fields.
--
commit f711eb495ad18e2339b40d0c737023fdb3459a71
Author: Wanpeng Li <wanpengli@tencent.com>
KVM: x86/lapic: Clear IPI tracking on matching-vector EOI
This commit updates apic_set_eoi() and kvm_apic_set_eoi_accelerated() to
clear IPI tracking state only when the EOI vector matches the tracked
vector, aiming to prevent eviction of pending contexts when unrelated
interrupts are handled.
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
[ ... ]
> +static void kvm_clear_ipi_on_eoi(struct kvm_lapic *apic, int vector)
> +{
> + struct kvm_vcpu *receiver = apic->vcpu;
> + struct kvm_vcpu *sender;
> + int sender_idx;
> + u64 then, now;
> +
> + if (unlikely(!READ_ONCE(ipi_tracking_enabled)))
> + return;
> +
> + if (vector < 0 || vector > 0xff)
> + return;
> +
> + if (READ_ONCE(receiver->arch.ipi_context.vector) != (u8)vector)
> + return;
> +
> + sender_idx = READ_ONCE(receiver->arch.ipi_context.last_ipi_sender);
> + kvm_vcpu_clear_ipi_context(receiver);
[Severity: Medium]
Does calling kvm_vcpu_clear_ipi_context() here unintentionally clear the
vCPU's outgoing IPI tracking state?
Looking at kvm_vcpu_clear_ipi_context(), it clears the entire ipi_context
structure, including pending_ipi and last_ipi_receiver. Since a vCPU can
act as both a sender and a receiver concurrently, acknowledging an incoming
IPI here appears to erase the vCPU's state as a sender.
Could this destroy the directed yield hint and cause concurrent IPI sender
and receiver vCPUs to miss the yield optimization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612013355.59231-1-kernellwp@gmail.com?part=8
next prev parent reply other threads:[~2026-06-12 3:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 1:33 [PATCH v3 00/10] sched/fair, KVM: Semantics-aware directed yield for oversubscribed KVM Wanpeng Li
2026-06-12 1:33 ` [PATCH v3 01/10] sched/fair: Add EEVDF lag credit primitive for nominated next-buddy Wanpeng Li
2026-06-12 1:49 ` sashiko-bot
2026-06-12 5:34 ` K Prateek Nayak
2026-06-12 1:33 ` [PATCH v3 02/10] sched/fair: Credit a persistent, queue-depth-scaled vlag margin Wanpeng Li
2026-06-12 1:53 ` sashiko-bot
2026-06-12 6:07 ` K Prateek Nayak
2026-06-12 1:33 ` [PATCH v3 03/10] sched/fair: Credit queued next-buddy via canonical requeue Wanpeng Li
2026-06-12 1:55 ` sashiko-bot
2026-06-12 1:33 ` [PATCH v3 04/10] sched/fair: Credit nominated next-buddy in yield_to_task_fair() Wanpeng Li
2026-06-12 1:54 ` sashiko-bot
2026-06-12 1:33 ` [PATCH v3 05/10] sched/fair: Force a local resched on yield_to() so the buddy is picked Wanpeng Li
2026-06-12 1:50 ` sashiko-bot
2026-06-12 1:33 ` [PATCH v3 06/10] KVM: x86: Add IPI tracking infrastructure for directed yield Wanpeng Li
2026-06-12 1:33 ` [PATCH v3 07/10] KVM: x86/lapic: Track unicast fixed IPI delivery Wanpeng Li
2026-06-12 1:33 ` [PATCH v3 08/10] KVM: x86/lapic: Clear IPI tracking on matching-vector EOI Wanpeng Li
2026-06-12 3:46 ` sashiko-bot [this message]
2026-06-12 1:33 ` [PATCH v3 09/10] KVM: Add IPI-aware directed-yield candidate selection Wanpeng Li
2026-06-12 1:48 ` sashiko-bot
2026-06-12 1:33 ` [PATCH v3 10/10] KVM: Add relaxed preempted-only fallback for directed yield Wanpeng Li
2026-06-12 5:17 ` [PATCH v3 00/10] sched/fair, KVM: Semantics-aware directed yield for oversubscribed KVM K Prateek Nayak
2026-06-12 9:43 ` Shrikanth Hegde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260612034633.023F11F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.