linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Zenghui Yu <yuzenghui@huawei.com>, Marc Zyngier <maz@kernel.org>
Cc: suzuki.poulose@arm.com, linux-kernel@vger.kernel.org,
	james.morse@arm.com, julien.thierry.kdev@gmail.com,
	wanghaibin.wang@huawei.com, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/3] KVM: arm/arm64: vgic: Don't rely on the wrong pending table
Date: Tue, 29 Oct 2019 23:52:02 +0100	[thread overview]
Message-ID: <40c96640-49b3-942b-59f7-3f2f1592d8d6@redhat.com> (raw)
In-Reply-To: <01638947-ce47-2e09-68f0-a95eb6e9b2d0@huawei.com>

Hi Zenghui,

On 10/29/19 2:31 PM, Zenghui Yu wrote:
> Hi Eric,
> 
> On 2019/10/29 20:49, Auger Eric wrote:
>> On 10/29/19 1:27 PM, Zenghui Yu wrote:
>>> okay, the remaining question is that in vgic_v3_save_pending_tables():
>>>
>>>      stored = val & (1U << bit_nr);
>>>      if (stored == irq->pending_latch)
>>>          continue;
>>>
>>>      if (irq->pending_latch)
>>>          val |= 1 << bit_nr;
>>>      else
>>>          val &= ~(1 << bit_nr);
>>>
>>> Do we really have a scenario where irq->pending_latch==false and
>>> stored==true (corresponds to the above "else") and then we clear
>>> pending status of this LPI in guest memory?
>>> I can not think out one now.
>>
>> if you save, restore and save again. On the 1st save the LPI may be
>> pending, it gets stored. On the second save the LPI may be not pending
>> anymore?
> 
> I assume you mean the "restore" by vgic_its_restore_ite().

yes that's what I meant

> 
> While restoring a LPI, we will sync the pending status from guest
> pending table (into the software pending_latch), and clear the
> corresponding bit in guest memory.
> See vgic_v3_lpi_sync_pending_status().
> 
> So on the second save, the LPI can be not pending, the guest pending
> table will also indicate not pending.

You're right; I did not remember vgic_v3_lpi_sync_pending_status (called
from vgic_its_restore_ite/vgic_add_lpi) "cleared the consumed data"
(44de9d683847  KVM: arm64: vgic-v3: vgic_v3_lpi_sync_pending_status).

So effectively after restore the pending table is zeroed and the above
code should be rewrittable in a more simple manner, ie. just update the
byte in case the pending_latch is set.

Nethertheless your patch indeed fixes an actual bug independently on
this cleanup, ie. the written byte may be incorrect if LPIs belonging to
this byte target different RDIST.

Thanks

Eric
> 
> 
> Thanks,
> Zenghui
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-10-29 22:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29  7:19 [PATCH 0/3] KVM: arm/arm64: vgic: Some cleanups and fixes Zenghui Yu
2019-10-29  7:19 ` [PATCH 1/3] KVM: arm/arm64: vgic: Remove the declaration of kvm_send_userspace_msi() Zenghui Yu
2019-10-29 12:29   ` Auger Eric
2019-10-29  7:19 ` [PATCH 2/3] KVM: arm/arm64: vgic: Fix some comments typo Zenghui Yu
2019-10-29  9:04   ` Marc Zyngier
2019-10-29 12:45     ` Zenghui Yu
2019-10-29 13:22       ` Marc Zyngier
2019-10-29  7:19 ` [PATCH 3/3] KVM: arm/arm64: vgic: Don't rely on the wrong pending table Zenghui Yu
2019-10-29  9:23   ` Marc Zyngier
2019-10-29 12:27     ` Zenghui Yu
2019-10-29 12:49       ` Auger Eric
2019-10-29 13:31         ` Zenghui Yu
2019-10-29 22:52           ` Auger Eric [this message]
2019-10-29 12:17   ` Auger Eric
2019-10-29 12:30     ` Zenghui Yu

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=40c96640-49b3-942b-59f7-3f2f1592d8d6@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=wanghaibin.wang@huawei.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).