mainline inclusion
from mainline-v5.18-rc2
commit af27e416
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I66S8J
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af27e41612ec7e5b4783f589b753a7c31a37aac8

----------------------------------------------------

The way KVM drives GICv4.{0,1} is as follows:
- vcpu_load() makes the VPE resident, instructing the RD to start
  scanning for interrupts
- just before entering the guest, we check that the RD has finished
  scanning and that we can start running the vcpu
- on preemption, we deschedule the VPE by making it invalid on
  the RD

However, we are preemptible between the first two steps. If it so
happens *and* that the RD was still scanning, we nonetheless write
to the GICR_VPENDBASER register while Dirty is set, and bad things
happen (we're in UNPRED land).

This affects both the 4.0 and 4.1 implementations.

Make sure Dirty is cleared before performing the deschedule,
meaning that its_clear_vpend_valid() becomes a sort of full VPE
residency barrier.
Reported-by: NJingyi Wang <wangjingyi11@huawei.com>
Tested-by: NNianyao Tang <tangnianyao@huawei.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Fixes: 57e3cebd ("KVM: arm64: Delay the polling of the GICR_VPENDBASER.Dirty bit")
Link: https://lore.kernel.org/r/4aae10ba-b39a-5f84-754b-69c2eb0a2c03@huawei.comSigned-off-by: NZenghui Yu <yuzenghui@huawei.com>
Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
(cherry picked from commit eeced70e)