Re: [PATCH] KVM: arm64: vgic-v3: Don't load pending state when enabling LPIs on RD

[Marc Zyngier <maz@kernel.org>]

Hi Zenghui,

On Thu, 07 Mar 2024 09:00:42 +0000,
Zenghui Yu <yuzenghui@huawei.com> wrote:
> 
> So I've tested it with kvm-unit-tests and got failure with the
> its-pending-migration case:
> 
> INFO: gicv3: its-pending-migration: Migration complete
> INFO: gicv3: its-pending-migration: expected 128 LPIs on PE #30, 0 observed
> FAIL: gicv3: its-pending-migration: 128 LPIs on both PE0 and PE1 after
> migration
> SUMMARY: 1 tests, 1 unexpected failures
> 
> where the guest SW directly writes to the pending table when
> GICR_CTLR.EnableLPIs == 0. I seriously doubt there is any use case like
> that in real world. But not sure whether it is a funky behaviour from
> the architectural perspective.

Right, so this is *exactly* the thing I was worried about. A mapping
has been established, the interrupt wasn't pending, all good. Now, an
interrupt lands while GICR_CTLR.EnableLPIs == 0.

The spec says (4.7.3 "Effect of disabling interrupts")

  "When GICR_CTLR.EnableLPIs == 0, LPIs are never set pending."

which to me is a pretty damning indication that we shouldn't take
these bits into account.

Of course, there is a grey area, in the sense that when we restore an
LPI via the restore interface, we are actually consuming pending bits
before EnableLPIs is set to 1.

But I would tend to draw the line between an interrupt that is
restored as part of rebuilding the KVM state, and an interrupt that is
forcefully injected behind our back.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.