[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01638947-ce47-2e09-68f0-a95eb6e9b2d0@huawei.com>
Date: Tue, 29 Oct 2019 21:31:18 +0800
From: Zenghui Yu <yuzenghui@...wei.com>
To: Auger Eric <eric.auger@...hat.com>, Marc Zyngier <maz@...nel.org>
CC: <suzuki.poulose@....com>, <linux-kernel@...r.kernel.org>,
<james.morse@....com>, <julien.thierry.kdev@...il.com>,
<wanghaibin.wang@...wei.com>, <kvmarm@...ts.cs.columbia.edu>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 3/3] KVM: arm/arm64: vgic: Don't rely on the wrong pending
table
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().
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.
Thanks,
Zenghui
Powered by blists - more mailing lists