From: Marc Zyngier <maz@kernel.org>
To: Kunkun Jiang <jiangkunkun@huawei.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Thomas Gleixner <tglx@linutronix.de>,
<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
<wanghaibin.wang@huawei.com>
Subject: Re: [PATCH v2 2/2] irqchip/gic-v4.1: Fix skipping VMOVP in cpu offline scenario
Date: Fri, 26 Jan 2024 10:52:57 +0000 [thread overview]
Message-ID: <86sf2k74dy.wl-maz@kernel.org> (raw)
In-Reply-To: <20240126103012.1020-3-jiangkunkun@huawei.com>
On Fri, 26 Jan 2024 10:30:12 +0000,
Kunkun Jiang <jiangkunkun@huawei.com> wrote:
>
> commit dd3f050a216e ("irqchip/gic-v4.1: Implement the v4.1 flavour
> of VMOVP") make an optimization, VMOVP can be skipped if moving
> VPE to a cpu whose RD is sharing its VPE table with the current one.
>
> In the cpu offline scenario, the mask_val is the entire cpu range,
> except for the offline cpu. Therefore, the first cpu is CPU0. In
> corner case, this may result in lost interrupts:
> 0. Each cpu die shares a VPE table and contains 32 CPUs
> die0(CPU0-31) die1(CPU32-63)...
> 1. VPE resides on CPU32, doorbell affinity to CPU32.
> 2. Move VPE to CPU16, doorbell affinity to CPU16.
> 3. Manually offline CPU16 on the host side:
> 'echo 0 > /sys/devices/system/cpu/cpu16/online'
> 4. VMOVP will be skipped.
> 5. Subsequent doorbell interrupts will be lost.
>
> So VMOVP cannot be skipped when the affinity CPU is not in mask_val.
>
> Fixes: dd3f050a216e ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP")
> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 4b1dbb697959..bfb922f16bc6 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3817,7 +3817,7 @@ static int its_vpe_set_affinity(struct irq_data *d,
> bool force)
> {
> struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
> - int from, cpu = cpumask_first(mask_val);
> + int cur, from, cpu = cpumask_first(mask_val);
> unsigned long flags;
>
> /*
> @@ -3839,11 +3839,13 @@ static int its_vpe_set_affinity(struct irq_data *d,
>
> vpe->col_idx = cpu;
>
> + cur = cpumask_first(irq_data_get_effective_affinity_mask(d));
When is this not equal to 'from'?
> /*
> * GICv4.1 allows us to skip VMOVP if moving to a cpu whose RD
> * is sharing its VPE table with the current one.
> */
> if (gic_data_rdist_cpu(cpu)->vpe_table_mask &&
> + cpumask_test_cpu(cur, mask_val) &&
> cpumask_test_cpu(from, gic_data_rdist_cpu(cpu)->vpe_table_mask))
> goto out;
This looks utterly pointless to me.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-26 10:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 10:30 [PATCH v2 0/2] irqchip/gic-v4.1: Two bugfixes about doorbell affinity Kunkun Jiang
2024-01-26 10:30 ` [PATCH v2 1/2] irqchip/gic-v4.1: Fix GICv4.1 " Kunkun Jiang
2024-01-26 10:52 ` Marc Zyngier
2024-01-27 2:41 ` Kunkun Jiang
2024-01-28 13:28 ` Marc Zyngier
2024-01-30 13:32 ` Kunkun Jiang
2024-01-30 13:55 ` Marc Zyngier
2024-01-31 1:29 ` Kunkun Jiang
2024-01-31 14:05 ` Marc Zyngier
2024-01-26 10:30 ` [PATCH v2 2/2] irqchip/gic-v4.1: Fix skipping VMOVP in cpu offline scenario Kunkun Jiang
2024-01-26 10:52 ` Marc Zyngier [this message]
2024-01-27 2:59 ` Kunkun Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86sf2k74dy.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=james.morse@arm.com \
--cc=jiangkunkun@huawei.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=wanghaibin.wang@huawei.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).