]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update
authorMarc Zyngier <maz@kernel.org>
Tue, 13 Feb 2024 10:12:06 +0000 (10:12 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 23 Feb 2024 07:42:29 +0000 (08:42 +0100)
commit888679afbfc2a071785b75ac5b02d5f3bee8de2a
tree8fc140300f1268e1b0f3355ddb5158e9fd55b788
parent2809645d8ae266e74279ac3e48b00a2d36985437
irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update

commit af9acbfc2c4b72c378d0b9a2ee023ed01055d3e2 upstream.

When updating the affinity of a VPE, the VMOVP command is currently skipped
if the two CPUs are part of the same VPE affinity.

But this is wrong, as the doorbell corresponding to this VPE is still
delivered on the 'old' CPU, which screws up the balancing.  Furthermore,
offlining that 'old' CPU results in doorbell interrupts generated for this
VPE being discarded.

The harsh reality is that VMOVP cannot be elided when a set_affinity()
request occurs. It needs to be obeyed, and if an optimisation is to be
made, it is at the point where the affinity change request is made (such as
in KVM).

Drop the VMOVP elision altogether, and only use the vpe_table_mask
to try and stay within the same ITS affinity group if at all possible.

Fixes: dd3f050a216e (irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP)
Reported-by: Kunkun Jiang <jiangkunkun@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20240213101206.2137483-4-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/irqchip/irq-gic-v3-its.c