All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fuad Tabba <fuad.tabba@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH v2 2/2] KVM: arm64: vgic-its: Remove the pending state of a discarded LPI
Date: Sat, 17 Oct 2026 08:40:21 +0100	[thread overview]
Message-ID: <20261017074021.1948168-1-fuad.tabba@linux.dev> (raw)
In-Reply-To: <867bjh1w52.wl-maz@kernel.org>

Hi Marc,

On Fri, 16 Oct 2026 16:51:37 +0100, Marc Zyngier <maz@kernel.org> wrote:
[...]
> > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
[...]
> > @@ -829,13 +829,27 @@ static int vgic_its_cmd_handle_discard(struct kvm *kvm, struct vgic_its *its,
[...]
> > +                /*
> > +                 * A queued LPI can be pending in a running vCPU's list register,
> > +                 * which the exit path folds back: halt the guest before clearing.
> > +                 */
> > +                scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> > +                        queued = irq->vcpu;
>
> Is this comment correct? This is only checking that the LPI is on the
> AP list of a vcpu, not that it is in the LRs.

The comment is correct but incomplete: it should say that only an LPI
on a vCPU's AP list can be in that vCPU's LRs, which is why the check
is enough.

> > +
> > +                if (queued)
> > +                        kvm_arm_halt_guest(kvm);
>
> And should we move this to kvm_pause_vcpu() instead of the big hammer,
> this still works because
>
> - we hold the ITS lock, so no MOVI can be issued on the same ITS
>
> - mapping of the same LPI is already prevented by the previous patch,
>   so no sneaky MOVI generated somewhere else can impact this LPI
>
> Do you agree?

Agreed, with one gap: a MOVI that completed before the DISCARD leaves
the LPI on the old vCPU's AP list until that vCPU's next exit. Pausing
irq->vcpu forces that exit, vgic_prune_ap_list() moves the LPI to the
new target and kicks it, and the target can load it into an LR before
pending_latch is cleared. Your two points keep target_vcpu stable, so
pausing the target as well closes that.

I forced the window with a delay between the pause and the clear: after
a MOVI and then a DISCARD, the new target takes the discarded LPI in
every run with only irq->vcpu paused, and doesn't take it in any run
with the target paused too.

[...]
> If you're OK with the above, I'll make the corresponding changes as I
> apply the patches.

Yes please, with the target paused as well.

Cheers,
/fuad

  reply	other threads:[~2026-10-17  7:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  8:16 [PATCH v2 0/2] KVM: arm64: vgic-its: Fix LPI double mapping and DISCARD Fuad Tabba
2026-10-13  8:16 ` [PATCH v2 1/2] KVM: arm64: vgic-its: Don't map an LPI from more than one event Fuad Tabba
2026-10-13  8:16 ` [PATCH v2 2/2] KVM: arm64: vgic-its: Remove the pending state of a discarded LPI Fuad Tabba
2026-10-13  8:50   ` sashiko-bot
2026-10-13  9:49     ` Oliver Upton
2026-10-16 15:51   ` Marc Zyngier
2026-10-17  7:40     ` Fuad Tabba [this message]
2026-10-17  7:47       ` Fuad Tabba
2026-10-13  9:51 ` [PATCH v2 0/2] KVM: arm64: vgic-its: Fix LPI double mapping and DISCARD Oliver Upton
2026-10-13 10:01   ` Marc Zyngier
2026-10-13 10:50     ` Fuad Tabba
2026-10-13 11:16       ` Marc Zyngier
2026-10-13 12:59         ` Fuad Tabba
2026-10-13 13:25           ` Marc Zyngier
2026-10-13 14:33             ` Fuad Tabba
2026-10-14 13:34               ` Marc Zyngier
2026-10-14 15:20                 ` Fuad Tabba

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=20261017074021.1948168-1-fuad.tabba@linux.dev \
    --to=fuad.tabba@linux.dev \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /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.