From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08AA8181334 for ; Fri, 2 Oct 2026 10:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790937670; cv=none; b=ldPviQvOnmjOah4uFoCpVhlJl3cUA59aDIrgptpAaCpqgXsqR+wHRSOW6DhW4K1smIfDuZbYiAZb5T+iTTScwbveo/SII0feKEKdF2F9m32cGYuScuTYvzxzVteRUy8hvmOJwy1gNGEufziXEWVvDxG5wYChpNlGoBp7PTXVHAE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790937670; c=relaxed/simple; bh=z0ND3Ww8zoPM+K2t8eYIfdnb/HnbN+iIfzfituG5V8k=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=nvirtVYLjdsuBg64lTHIDvT+ng8qVOzzAfvwlrYJeGqeugVYZ5XJk1Hv+diDPW+1LEKMBVuFNFgP3UEfe9oSN0b72A4DrrmuFqjGcdtT+L1ClOiDCFJtvDJF50JX7iRll3Xlqwza263KN+ZQI+DKnu4jyp+XTYrVhNe/Ip/KSLo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JoaqbHN6; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JoaqbHN6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8669D1F000FF; Fri, 2 Oct 2026 10:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790937668; bh=o+7IPeeFzPJKtwHy7SCfMdgiQ6yzVRdN57jTWIyI72o=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=JoaqbHN6nIdnPNGDjJfyq5pz87f9pDHZ0v4cB21YsKw4JPKMukdkX1IAXnDJrETAB H0CZIJyprM1dF/TGa8Vhy9t7V9fAvrg/yaOkzwwTrc/AcOv577caUPnLSo6AavHx4k jF+SGsWbwJL65CzmCKup5+qJBCmWf6GntDVL+OMJB0lhOhKyH/kEpnMnYOa4RLOfO1 HUMlgttXsg9j40Xa1BS3vcag0BlIyYAUeNGeuqiuHrWDwdvg3Ci15P1idz6TdjyDYC d1OZ+B9rw1ZXGmboDrxmPrKslrvvaaxX7DQLEKcOO194bz22r0FYkLXcE5ND8SlMVw bqJ5TJ/XAd4PA== From: sashiko-bot@kernel.org Subject: Re: [PATCH 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003 Reply-To: sashiko-reviews@lists.linux.dev To: "Tomohiro Misono" Cc: linux-perf-users@vger.kernel.org In-Reply-To: <20261002-monaka-fix-for-upstream-v1-4-4aec0b0cbe34@fujitsu.com> References: <20261002-monaka-fix-for-upstream-v1-0-4aec0b0cbe34@fujitsu.com> <20261002-monaka-fix-for-upstream-v1-4-4aec0b0cbe34@fujitsu.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 02 Oct 2026 10:41:08 +0000 Message-Id: <20261002104108.8669D1F000FF@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] irqchip/gicv3: CONSTRAINED UNPREDICTABLE access to sleeping redist= ributor -- commit d6fd070c2b4a77ad65839152f8e6343482132aff Author: Kohei Enju irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003 This commit adds a workaround for FUJITSU-MONAKA erratum E#030003, where SGIs generated by system register writes may be lost. The workaround changes the IPI delivery mechanism to write directly to the target CPU's GICR_ISPENDR0 register instead of using ICC_SGI1R_EL1. [ ... ] > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 6e1fa5b247fc4..e73fea8a0e279 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c [ ... ] > @@ -1373,6 +1378,13 @@ static void gic_send_sgi(u64 cluster_id, u16 tlist= , unsigned int irq) > gic_write_sgi1r(val); > } > =20 > +static void gic_send_sgi_via_rdist(int cpu, unsigned int irq) > +{ > + void __iomem *base =3D gic_data_rdist_sgi_base_cpu(cpu); > + > + writel_relaxed(BIT(irq), base + GICR_ISPENDR0); [Severity: High] Does this access handle the case where the target CPU is in deep idle (ProcessorSleep =3D=3D 1)? The GICv3 architecture mandates that accessing GICR_ registers (other than GICR_WAKER) while ProcessorSleep =3D=3D 1 is constrained unpredictable. When a CPU enters deep idle, gic_enable_redist(false) sets GICR_WAKER_ProcessorSleep. If another CPU sends an IPI to this idle CPU (e.g., a scheduler wake-up), it executes gic_send_sgi_via_rdist() which directly writes to the sleeping redistributor's MMIO register. Bypassing ICC_SGI1R_EL1 and writing directly to GICR_ISPENDR0 could break standard IPI delivery to idle CPUs by either causing a synchronous external abort or dropping the IPI. > +} --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261002-monaka-fix= -for-upstream-v1-0-4aec0b0cbe34@fujitsu.com?part=3D4