irqchip/gic-v4: Correctly deal with set_affinity on lazily-mapped VPEs
Subsystems (2)
Marc Zyngier
maintainerPATCH 1/1 irqchip/gic-v4: Correctly deal with set_affinity on lazily-mapped VPEs
Zenghui points out that a recent change to the way set_affinity is handled for VPEs has the potential to return an error if the VPE hasn't been mapped yet (because the guest hasn't emited a MAPTI command yet), affecting GICv4.0 implementations that rely on the ITSList feature.
Fix this by making the set_affinity succeed in this case, and return early, without trying to touch the HW.
--- drivers/irqchip/irq-gic-v3-its.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/irqchip/irq-gic-v3-its.c +12 -2
@@ -3810,8 +3810,18 @@ static int its_vpe_set_affinity(struct irq_data *d,* Check if we're racing against a VPE being destroyed, for * which we don't want to allow a VMOVP. */ -if (!atomic_read (&vpe->vmapp_count)) -return -EINVAL ; +if (!atomic_read (&vpe->vmapp_count)) { +if (gic_requires_eager_mapping ()) +return -EINVAL ; + +/* +* If we lazily map the VPEs, this isn't an error and +* we can exit cleanly. +*/ + cpu =cpumask_first (mask_val); +irq_data_update_effective_affinity (d,cpumask_of (cpu)); +return IRQ_SET_MASK_OK_DONE ; + }/* * Changing affinity is mega expensive, so let's be as lazy as
Signature · 1 line
2.39.2
The following commit has been merged into the irq/urgent branch of tip:
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: e6c24e2d05bb05de96ffb9bdb0ee62d20ad526f8 Gitweb: https://git.kernel.org/tip/e6c24e2d05bb05de96ffb9bdb0ee62d20ad526f8 Author: Marc Zyngier <[email protected]> AuthorDate: Sun, 27 Oct 2024 10:22:20 Committer: Thomas Gleixner <[email protected]> CommitterDate: Sun, 27 Oct 2024 17:30:16 +01:00
irqchip/gic-v4: Correctly deal with set_affinity on lazily-mapped VPEs
Zenghui points out that a recent change to the way set_affinity is handled for VPEs has the potential to return an error if the VPE hasn't been mapped yet (because the guest hasn't emited a MAPTI command yet), affecting GICv4.0 implementations that rely on the ITSList feature.
Fix this by making the set_affinity succeed in this case, and return early, without trying to touch the HW.
--- drivers/irqchip/irq-gic-v3-its.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/irqchip/irq-gic-v3-its.c +12 -2
@@ -3810,8 +3810,18 @@ static int its_vpe_set_affinity(struct irq_data *d,* Check if we're racing against a VPE being destroyed, for * which we don't want to allow a VMOVP. */ -if (!atomic_read (&vpe->vmapp_count)) -return -EINVAL ; +if (!atomic_read (&vpe->vmapp_count)) { +if (gic_requires_eager_mapping ()) +return -EINVAL ; + +/* +* If we lazily map the VPEs, this isn't an error and +* we can exit cleanly. +*/ + cpu =cpumask_first (mask_val); +irq_data_update_effective_affinity (d,cpumask_of (cpu)); +return IRQ_SET_MASK_OK_DONE ; + }/* * Changing affinity is mega expensive, so let's be as lazy as