From: Christoffer Dall <christoffer.dall@linaro.org>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: 'Marc Zyngier' <marc.zyngier@arm.com>,
andre.przywara@arm.com, kvmarm@lists.cs.columbia.edu,
kvm@vger.kernel.org
Subject: Re: [PATCH v2] KVM: arm/arm64: BUG FIX: Do not inject spurious interrupts
Date: Sat, 10 Oct 2015 17:00:36 +0200 [thread overview]
Message-ID: <20151010150036.GC29128@cbox> (raw)
In-Reply-To: <01b701d102a0$8b19c5c0$a14d5140$@samsung.com>
On Fri, Oct 09, 2015 at 05:41:11PM +0300, Pavel Fedin wrote:
> Hello!
>
> > I reworked the commit message and applied this patch.
>
> During testing i discovered a problem with this patch and vITS series by Andre.
> The problem is that compute_pending_for_cpu() does not know anything about LPIs. Therefore, we can
> reset this bit even if some LPIs (and only LPIs) are pending. This causes LPI loss.
I haven't looked at the ITS series in detail yet so I cannot commetn on
this.
> This is the confirmation of that clearing irq_pending_on_cpu anywhere else than
> __kvm_vgic_flush_hwstate() is a bad idea. I would suggest to stick back to v1 of the patch (without
> clearing this bit). We can add a clarifying description to the commit message like this:
>
> --- cut ---
> In some situations level-sensitive IRQ disappears before it has been
> processed. This is normal, and in this situation we lose this IRQ, the same
> as real HW does. The aim of this patch is to handle this situation more
> correctly. However, dist->irq_pending_on_cpu stays set until the vCPU
> itself rechecks its status. Therefore, this bit does not guarantee that
> something is pending at the given moment, it should be treated as attention
> flag, saying that something has happened on this vCPU, and it could have
> been even gone since that, but wakeup and status recheck is needed.
> --- cut ---
I really don't want to have an inconsistent state in our data
structures, this whole thing is plenty fragile as it is.
>
> Would you be happy with this? An alternative would be to add a check for pending LPIs, but wouldn't
> it just be too complex for a simple problem?
>
My concern at this point is to try to keep this thing stable.
It is really up to whoever adds support for LPIs to make sure it's done
correctly. So I think this is for Andre to work out in his ITS series.
This patch fixes an issue with the current code in the correct way as
far as I can tell.
Thanks,
-Christoffer
next prev parent reply other threads:[~2015-10-10 14:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 14:00 [PATCH v2] KVM: arm/arm64: BUG FIX: Do not inject spurious interrupts Pavel Fedin
2015-09-29 7:25 ` Christoffer Dall
2015-09-30 10:24 ` Pavel Fedin
2015-10-09 14:41 ` Pavel Fedin
2015-10-10 15:00 ` Christoffer Dall [this message]
2015-10-12 7:14 ` Pavel Fedin
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=20151010150036.GC29128@cbox \
--to=christoffer.dall@linaro.org \
--cc=andre.przywara@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=p.fedin@samsung.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.