* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Daniel Baluta @ 2026-03-24 10:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <20260324-smoky-radical-hyrax-1274a9@quoll>
On 3/24/26 11:26, Krzysztof Kozlowski wrote:
> On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
>> Running DTBS checks on st/spear1340-evb.dtb results in the following
>> warning:
>>
>> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
>> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
> How is it possible if there is no such file?
>
> Did you just add new warning in patch #1 and then claim in patch #2 that
> you fix it?
>
> You completely miss the point why this change is needed: how could the
> DTS work before? It could not. And that should be your justification for
> the patch, with explanation why it could not work.
Correct me if I'm wrong but I think there was a hidden bug here
drivers/thermal/spear_thermal.c:spear_thermal_probe:
if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
» » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
» » return -EINVAL;
» }
So, the driver was checking for the correct property as pointed by
bindings/thermal/spear-thermal.txt but the dts was using the wrong
property name: arch/arm/boot/dts/st/spear13xx.dtsi » » » thermal@e07008c4 { » » » » compatible = "st,thermal-spear1340"; » » » » reg = <0xe07008c4 0x4>; » » » » thermal_flags = <0x7000>; » » » }; And because this check is wrong:
if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
people really didn't notice it.
The check should be:
if (!np || of_property_read_u32(np, "st,thermal-flags", &val)) {
» » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
» » return -EINVAL;
» }
So, this actual patch has uncovered a bug!
^ permalink raw reply
* Re: [PATCH] arm64: vdso: fix AArch32 compat init allocation leaks
From: Will Deacon @ 2026-03-24 9:59 UTC (permalink / raw)
To: Osama Abdelkader
Cc: Catalin Marinas, Kees Cook, Andrew Morton, Liam R. Howlett,
Jeff Xu, linux-arm-kernel, linux-kernel
In-Reply-To: <20260323214117.241216-1-osama.abdelkader@gmail.com>
On Mon, Mar 23, 2026 at 10:41:16PM +0100, Osama Abdelkader wrote:
> aarch32_alloc_vdso_pages() allocates the AA32 vdso pagelist, the compat
> sigpage, then the kuser vectors page. If aarch32_alloc_sigpage() or
> aarch32_alloc_kuser_vdso_page() fails, earlier allocations were not freed.
But why should they be freed? The vectors, sigpage and vdso are
independent from one another, so we can limp along with whatever we
managed to allocate. I'm not sure how far we'll get, mind, if single
page allocations are failing at initcall time...
Will
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Krzysztof Kozlowski @ 2026-03-24 10:01 UTC (permalink / raw)
To: Daniel Baluta, Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <cd3400ce-295e-450f-b650-6715142ccbde@nxp.com>
On 24/03/2026 11:00, Daniel Baluta wrote:
> On 3/24/26 11:26, Krzysztof Kozlowski wrote:
>> On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
>>> Running DTBS checks on st/spear1340-evb.dtb results in the following
>>> warning:
>>>
>>> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
>>> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
>> How is it possible if there is no such file?
>>
>> Did you just add new warning in patch #1 and then claim in patch #2 that
>> you fix it?
>>
>> You completely miss the point why this change is needed: how could the
>> DTS work before? It could not. And that should be your justification for
>> the patch, with explanation why it could not work.
>
> Correct me if I'm wrong but I think there was a hidden bug here
>
> drivers/thermal/spear_thermal.c:spear_thermal_probe:
>
> if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
> » » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
> » » return -EINVAL;
> » }
>
> So, the driver was checking for the correct property as pointed by
Yes
>
> bindings/thermal/spear-thermal.txt but the dts was using the wrong
No, DTS had two properties - correct one and incorrect.
>
> property name: arch/arm/boot/dts/st/spear13xx.dtsi » » » thermal@e07008c4 { » » » » compatible = "st,thermal-spear1340"; » » » » reg = <0xe07008c4 0x4>; » » » » thermal_flags = <0x7000>; » » » }; And because this check is wrong:
>
> if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
>
> people really didn't notice it.
>
> The check should be:
>
> if (!np || of_property_read_u32(np, "st,thermal-flags", &val)) {
> » » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
> » » return -EINVAL;
> » }
>
> So, this actual patch has uncovered a bug!
Yes. Driver also has bug, so probably was never working. The point is
whatever commit is doing, the dtbs_check warning is not the
justification, because it was introduced by this patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ACPI: APEI: Handle repeated SEA error interrupts storm scenarios
From: hejunhao @ 2026-03-24 10:04 UTC (permalink / raw)
To: Shuai Xue, Rafael J. Wysocki, Luck, Tony
Cc: bp, guohanjun, mchehab, jarkko, yazen.ghannam, jane.chu, lenb,
Jonathan.Cameron, linux-acpi, linux-arm-kernel, linux-kernel,
linux-edac, shiju.jose, tanxiaofei, Junhao He, Linuxarm
In-Reply-To: <70b85b7c-5107-4f79-abf7-3cc5b7e1438d@linux.alibaba.com>
Hi shuai xue,
On 2026/3/3 22:42, Shuai Xue wrote:
> Hi, junhao,
>
> On 2/27/26 8:12 PM, hejunhao wrote:
>>
>>
>> On 2025/11/4 9:32, Shuai Xue wrote:
>>>
>>>
>>> 在 2025/11/4 00:19, Rafael J. Wysocki 写道:
>>>> On Thu, Oct 30, 2025 at 8:13 AM Junhao He <hejunhao3@h-partners.com> wrote:
>>>>>
>>>>> The do_sea() function defaults to using firmware-first mode, if supported.
>>>>> It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA
>>>>> error, The GHES uses a buffer to cache the most recent 4 kinds of SEA
>>>>> errors. If the same kind SEA error continues to occur, GHES will skip to
>>>>> reporting this SEA error and will not add it to the "ghes_estatus_llist"
>>>>> list until the cache times out after 10 seconds, at which point the SEA
>>>>> error will be reprocessed.
>>>>>
>>>>> The GHES invoke ghes_proc_in_irq() to handle the SEA error, which
>>>>> ultimately executes memory_failure() to process the page with hardware
>>>>> memory corruption. If the same SEA error appears multiple times
>>>>> consecutively, it indicates that the previous handling was incomplete or
>>>>> unable to resolve the fault. In such cases, it is more appropriate to
>>>>> return a failure when encountering the same error again, and then proceed
>>>>> to arm64_do_kernel_sea for further processing.
>
> There is no such function in the arm64 tree. If apei_claim_sea() returns
Sorry for the mistake in the commit message. The function arm64_do_kernel_sea() should
be arm64_notify_die().
> an error, the actual fallback path in do_sea() is arm64_notify_die(),
> which sends SIGBUS?
>
If apei_claim_sea() returns an error, arm64_notify_die() will call arm64_force_sig_fault(inf->sig /* SIGBUS */, , , ),
followed by force_sig_fault(SIGBUS, , ) to force the process to receive the SIGBUS signal.
>>>>>
>>>>> When hardware memory corruption occurs, a memory error interrupt is
>>>>> triggered. If the kernel accesses this erroneous data, it will trigger
>>>>> the SEA error exception handler. All such handlers will call
>>>>> memory_failure() to handle the faulty page.
>>>>>
>>>>> If a memory error interrupt occurs first, followed by an SEA error
>>>>> interrupt, the faulty page is first marked as poisoned by the memory error
>>>>> interrupt process, and then the SEA error interrupt handling process will
>>>>> send a SIGBUS signal to the process accessing the poisoned page.
>>>>>
>>>>> However, if the SEA interrupt is reported first, the following exceptional
>>>>> scenario occurs:
>>>>>
>>>>> When a user process directly requests and accesses a page with hardware
>>>>> memory corruption via mmap (such as with devmem), the page containing this
>>>>> address may still be in a free buddy state in the kernel. At this point,
>>>>> the page is marked as "poisoned" during the SEA claim memory_failure().
>>>>> However, since the process does not request the page through the kernel's
>>>>> MMU, the kernel cannot send SIGBUS signal to the processes. And the memory
>>>>> error interrupt handling process not support send SIGBUS signal. As a
>>>>> result, these processes continues to access the faulty page, causing
>>>>> repeated entries into the SEA exception handler. At this time, it lead to
>>>>> an SEA error interrupt storm.
>
> In such case, the user process which accessing the poisoned page will be killed
> by memory_fauilre?
>
> // memory_failure():
>
> if (TestSetPageHWPoison(p)) {
> res = -EHWPOISON;
> if (flags & MF_ACTION_REQUIRED)
> res = kill_accessing_process(current, pfn, flags);
> if (flags & MF_COUNT_INCREASED)
> put_page(p);
> action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
> goto unlock_mutex;
> }
>
> I think this problem has already been fixed by commit 2e6053fea379 ("mm/memory-failure:
> fix infinite UCE for VM_PFNMAP pfn").
>
> The root cause is that walk_page_range() skips VM_PFNMAP vmas by default when
> no .test_walk callback is set, so kill_accessing_process() returns 0 for a
> devmem-style mapping (remap_pfn_range, VM_PFNMAP), making the caller believe
> the UCE was handled properly while the process was never actually killed.
>
> Did you try the lastest kernel version?
>
I retested this issue on the kernel v7.0.0-rc4 with the following debug patch and was still able to reproduce it.
@@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
/* This error has been reported before, don't process it again. */
- if (ghes_estatus_cached(estatus))
+ if (ghes_estatus_cached(estatus)) {
+ pr_info("This error has been reported before, don't process it again.\n");
goto no_work;
+ }
the test log Only some debug logs are retained here.
[2026/3/24 14:51:58.199] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
[2026/3/24 14:51:58.369] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
[2026/3/24 14:51:58.458] [ 130.558038][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
[2026/3/24 14:51:58.459] [ 130.572517][ C40] {1}[Hardware Error]: event severity: recoverable
[2026/3/24 14:51:58.459] [ 130.578861][ C40] {1}[Hardware Error]: Error 0, type: recoverable
[2026/3/24 14:51:58.459] [ 130.585203][ C40] {1}[Hardware Error]: section_type: ARM processor error
[2026/3/24 14:51:58.459] [ 130.592238][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
[2026/3/24 14:51:58.459] [ 130.598492][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
[2026/3/24 14:51:58.459] [ 130.607871][ C40] {1}[Hardware Error]: error affinity level: 0
[2026/3/24 14:51:58.459] [ 130.614038][ C40] {1}[Hardware Error]: running state: 0x1
[2026/3/24 14:51:58.459] [ 130.619770][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
[2026/3/24 14:51:58.459] [ 130.627673][ C40] {1}[Hardware Error]: Error info structure 0:
[2026/3/24 14:51:58.459] [ 130.633839][ C40] {1}[Hardware Error]: num errors: 1
[2026/3/24 14:51:58.459] [ 130.639137][ C40] {1}[Hardware Error]: error_type: 0, cache error
[2026/3/24 14:51:58.459] [ 130.645652][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
[2026/3/24 14:51:58.459] [ 130.652514][ C40] {1}[Hardware Error]: cache level: 1
[2026/3/24 14:51:58.551] [ 130.658073][ C40] {1}[Hardware Error]: the error has not been corrected
[2026/3/24 14:51:58.551] [ 130.665194][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
[2026/3/24 14:51:58.551] [ 130.673097][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
[2026/3/24 14:51:58.551] [ 130.680744][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
[2026/3/24 14:51:58.551] [ 130.690471][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
[2026/3/24 14:51:58.552] [ 130.700198][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
[2026/3/24 14:51:58.552] [ 130.710083][ T9767] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
[2026/3/24 14:51:58.638] [ 130.790952][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:51:58.903] [ 131.046994][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:51:58.991] [ 131.132360][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:51:59.969] [ 132.071431][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:00.860] [ 133.010255][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:01.927] [ 134.034746][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:02.906] [ 135.058973][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:03.971] [ 136.083213][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:04.860] [ 137.021956][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:06.018] [ 138.131460][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:06.905] [ 139.070280][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:07.886] [ 140.009147][ C40] This error has been reported before, don't process it again.
[2026/3/24 14:52:08.596] [ 140.777368][ C40] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
[2026/3/24 14:52:08.683] [ 140.791921][ C40] {2}[Hardware Error]: event severity: recoverable
[2026/3/24 14:52:08.683] [ 140.798263][ C40] {2}[Hardware Error]: Error 0, type: recoverable
[2026/3/24 14:52:08.683] [ 140.804606][ C40] {2}[Hardware Error]: section_type: ARM processor error
[2026/3/24 14:52:08.683] [ 140.811641][ C40] {2}[Hardware Error]: MIDR: 0x0000000000000000
[2026/3/24 14:52:08.684] [ 140.817895][ C40] {2}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
[2026/3/24 14:52:08.684] [ 140.827274][ C40] {2}[Hardware Error]: error affinity level: 0
[2026/3/24 14:52:08.684] [ 140.833440][ C40] {2}[Hardware Error]: running state: 0x1
[2026/3/24 14:52:08.684] [ 140.839173][ C40] {2}[Hardware Error]: Power State Coordination Interface state: 0
[2026/3/24 14:52:08.684] [ 140.847076][ C40] {2}[Hardware Error]: Error info structure 0:
[2026/3/24 14:52:08.684] [ 140.853241][ C40] {2}[Hardware Error]: num errors: 1
[2026/3/24 14:52:08.684] [ 140.858540][ C40] {2}[Hardware Error]: error_type: 0, cache error
[2026/3/24 14:52:08.684] [ 140.865055][ C40] {2}[Hardware Error]: error_info: 0x0000000020400014
[2026/3/24 14:52:08.684] [ 140.871917][ C40] {2}[Hardware Error]: cache level: 1
[2026/3/24 14:52:08.684] [ 140.877475][ C40] {2}[Hardware Error]: the error has not been corrected
[2026/3/24 14:52:08.764] [ 140.884596][ C40] {2}[Hardware Error]: physical fault address: 0x0000001351811800
[2026/3/24 14:52:08.764] [ 140.892499][ C40] {2}[Hardware Error]: Vendor specific error info has 48 bytes:
[2026/3/24 14:52:08.766] [ 140.900145][ C40] {2}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
[2026/3/24 14:52:08.767] [ 140.909872][ C40] {2}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
[2026/3/24 14:52:08.767] [ 140.919598][ C40] {2}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
[2026/3/24 14:52:08.768] [ 140.929346][ T9767] Memory failure: 0x1351811: already hardware poisoned
[2026/3/24 14:52:08.768] [ 140.936072][ T9767] Memory failure: 0x1351811: Sending SIGBUS to busybox:9767 due to hardware memory corruption
Apply the patch:
@@ -1365,8 +1365,11 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
/* This error has been reported before, don't process it again. */
- if (ghes_estatus_cached(estatus))
+ if (ghes_estatus_cached(estatus)) {
+ pr_info("This error has been reported before, don't process it again.\n");
+ rc = -ECANCELED;
goto no_work;
+ }
[2026/3/24 16:45:40.084] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32 0
[2026/3/24 16:45:40.272] [root@localhost ~]# taskset -c 40 busybox devmem 0x1351811824 32
[2026/3/24 16:45:40.362] [ 112.279324][ C40] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
[2026/3/24 16:45:40.362] [ 112.293797][ C40] {1}[Hardware Error]: event severity: recoverable
[2026/3/24 16:45:40.362] [ 112.300139][ C40] {1}[Hardware Error]: Error 0, type: recoverable
[2026/3/24 16:45:40.363] [ 112.306481][ C40] {1}[Hardware Error]: section_type: ARM processor error
[2026/3/24 16:45:40.363] [ 112.313516][ C40] {1}[Hardware Error]: MIDR: 0x0000000000000000
[2026/3/24 16:45:40.363] [ 112.319771][ C40] {1}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081010400
[2026/3/24 16:45:40.363] [ 112.329151][ C40] {1}[Hardware Error]: error affinity level: 0
[2026/3/24 16:45:40.363] [ 112.335317][ C40] {1}[Hardware Error]: running state: 0x1
[2026/3/24 16:45:40.363] [ 112.341049][ C40] {1}[Hardware Error]: Power State Coordination Interface state: 0
[2026/3/24 16:45:40.363] [ 112.348953][ C40] {1}[Hardware Error]: Error info structure 0:
[2026/3/24 16:45:40.363] [ 112.355119][ C40] {1}[Hardware Error]: num errors: 1
[2026/3/24 16:45:40.363] [ 112.360418][ C40] {1}[Hardware Error]: error_type: 0, cache error
[2026/3/24 16:45:40.363] [ 112.366932][ C40] {1}[Hardware Error]: error_info: 0x0000000020400014
[2026/3/24 16:45:40.363] [ 112.373795][ C40] {1}[Hardware Error]: cache level: 1
[2026/3/24 16:45:40.453] [ 112.379354][ C40] {1}[Hardware Error]: the error has not been corrected
[2026/3/24 16:45:40.453] [ 112.386475][ C40] {1}[Hardware Error]: physical fault address: 0x0000001351811800
[2026/3/24 16:45:40.453] [ 112.394378][ C40] {1}[Hardware Error]: Vendor specific error info has 48 bytes:
[2026/3/24 16:45:40.453] [ 112.402027][ C40] {1}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
[2026/3/24 16:45:40.453] [ 112.411754][ C40] {1}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
[2026/3/24 16:45:40.453] [ 112.421480][ C40] {1}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
[2026/3/24 16:45:40.453] [ 112.431639][ T9769] Memory failure: 0x1351811: recovery action for free buddy page: Recovered
[2026/3/24 16:45:40.531] [ 112.512520][ C40] This error has been reported before, don't process it again.
[2026/3/24 16:45:40.757] Bus error (core dumped)
>>>>>
>>>>> Fixes this by returning a failure when encountering the same error again.
>>>>>
>>>>> The following error logs is explained using the devmem process:
>>>>> NOTICE: SEA Handle
>>>>> NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400
>>>>> NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1]
>>>>> NOTICE: EsrEl3 = 0x92000410
>>>>> NOTICE: PA is valid: 0x1000093c00
>>>>> NOTICE: Hest Set GenericError Data
>>>>> [ 1419.542401][ C1] {57}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>>> [ 1419.551435][ C1] {57}[Hardware Error]: event severity: recoverable
>>>>> [ 1419.557865][ C1] {57}[Hardware Error]: Error 0, type: recoverable
>>>>> [ 1419.564295][ C1] {57}[Hardware Error]: section_type: ARM processor error
>>>>> [ 1419.571421][ C1] {57}[Hardware Error]: MIDR: 0x0000000000000000
>>>>> [ 1419.571434][ C1] {57}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081000100
>>>>> [ 1419.586813][ C1] {57}[Hardware Error]: error affinity level: 0
>>>>> [ 1419.586821][ C1] {57}[Hardware Error]: running state: 0x1
>>>>> [ 1419.602714][ C1] {57}[Hardware Error]: Power State Coordination Interface state: 0
>>>>> [ 1419.602724][ C1] {57}[Hardware Error]: Error info structure 0:
>>>>> [ 1419.614797][ C1] {57}[Hardware Error]: num errors: 1
>>>>> [ 1419.614804][ C1] {57}[Hardware Error]: error_type: 0, cache error
>>>>> [ 1419.629226][ C1] {57}[Hardware Error]: error_info: 0x0000000020400014
>>>>> [ 1419.629234][ C1] {57}[Hardware Error]: cache level: 1
>>>>> [ 1419.642006][ C1] {57}[Hardware Error]: the error has not been corrected
>>>>> [ 1419.642013][ C1] {57}[Hardware Error]: physical fault address: 0x0000001000093c00
>>>>> [ 1419.654001][ C1] {57}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>>> [ 1419.654014][ C1] {57}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>>> [ 1419.670685][ C1] {57}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>>> [ 1419.670692][ C1] {57}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>>> [ 1419.783606][T54990] Memory failure: 0x1000093: recovery action for free buddy page: Recovered
>>>>> [ 1419.919580][ T9955] EDAC MC0: 1 UE Multi-bit ECC on unknown memory (node:0 card:1 module:71 bank:7 row:0 col:0 page:0x1000093 offset:0xc00 grain:1 - APEI location: node:0 card:257 module:71 bank:7 row:0 col:0)
>>>>> NOTICE: SEA Handle
>>>>> NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400
>>>>> NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1]
>>>>> NOTICE: EsrEl3 = 0x92000410
>>>>> NOTICE: PA is valid: 0x1000093c00
>>>>> NOTICE: Hest Set GenericError Data
>>>>> NOTICE: SEA Handle
>>>>> NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400
>>>>> NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1]
>>>>> NOTICE: EsrEl3 = 0x92000410
>>>>> NOTICE: PA is valid: 0x1000093c00
>>>>> NOTICE: Hest Set GenericError Data
>>>>> ...
>>>>> ... ---> Hapend SEA error interrupt storm
>>>>> ...
>>>>> NOTICE: SEA Handle
>>>>> NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400
>>>>> NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1]
>>>>> NOTICE: EsrEl3 = 0x92000410
>>>>> NOTICE: PA is valid: 0x1000093c00
>>>>> NOTICE: Hest Set GenericError Data
>>>>> [ 1429.818080][ T9955] Memory failure: 0x1000093: already hardware poisoned
>>>>> [ 1429.825760][ C1] ghes_print_estatus: 1 callbacks suppressed
>>>>> [ 1429.825763][ C1] {59}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
>>>>> [ 1429.843731][ C1] {59}[Hardware Error]: event severity: recoverable
>>>>> [ 1429.861800][ C1] {59}[Hardware Error]: Error 0, type: recoverable
>>>>> [ 1429.874658][ C1] {59}[Hardware Error]: section_type: ARM processor error
>>>>> [ 1429.887516][ C1] {59}[Hardware Error]: MIDR: 0x0000000000000000
>>>>> [ 1429.901159][ C1] {59}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081000100
>>>>> [ 1429.901166][ C1] {59}[Hardware Error]: error affinity level: 0
>>>>> [ 1429.914896][ C1] {59}[Hardware Error]: running state: 0x1
>>>>> [ 1429.914903][ C1] {59}[Hardware Error]: Power State Coordination Interface state: 0
>>>>> [ 1429.933319][ C1] {59}[Hardware Error]: Error info structure 0:
>>>>> [ 1429.946261][ C1] {59}[Hardware Error]: num errors: 1
>>>>> [ 1429.946269][ C1] {59}[Hardware Error]: error_type: 0, cache error
>>>>> [ 1429.970847][ C1] {59}[Hardware Error]: error_info: 0x0000000020400014
>>>>> [ 1429.970854][ C1] {59}[Hardware Error]: cache level: 1
>>>>> [ 1429.988406][ C1] {59}[Hardware Error]: the error has not been corrected
>>>>> [ 1430.013419][ C1] {59}[Hardware Error]: physical fault address: 0x0000001000093c00
>>>>> [ 1430.013425][ C1] {59}[Hardware Error]: Vendor specific error info has 48 bytes:
>>>>> [ 1430.025424][ C1] {59}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................
>>>>> [ 1430.053736][ C1] {59}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................
>>>>> [ 1430.066341][ C1] {59}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................
>>>>> [ 1430.294255][T54990] Memory failure: 0x1000093: already hardware poisoned
>>>>> [ 1430.305518][T54990] 0x1000093: Sending SIGBUS to devmem:54990 due to hardware memory corruption
>>>>>
>>>>> Signed-off-by: Junhao He <hejunhao3@h-partners.com>
>>>>> ---
>>>>> drivers/acpi/apei/ghes.c | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>>>>> index 005de10d80c3..eebda39bfc30 100644
>>>>> --- a/drivers/acpi/apei/ghes.c
>>>>> +++ b/drivers/acpi/apei/ghes.c
>>>>> @@ -1343,8 +1343,10 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
>>>>> ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
>>>>>
>>>>> /* This error has been reported before, don't process it again. */
>>>>> - if (ghes_estatus_cached(estatus))
>>>>> + if (ghes_estatus_cached(estatus)) {
>>>>> + rc = -ECANCELED;
>>>>> goto no_work;
>>>>> + }
>>>>>
>>>>> llist_add(&estatus_node->llnode, &ghes_estatus_llist);
>>>>>
>>>>> --
>>>>
>>>> This needs a response from the APEI reviewers as per MAINTAINERS, thanks!
>>>
>>> Hi, Rafael and Junhao,
>>>
>>> Sorry for late response, I try to reproduce the issue, it seems that
>>> EINJ systems broken in 6.18.0-rc1+.
>>>
>>> [ 3950.741186] CPU: 36 UID: 0 PID: 74112 Comm: einj_mem_uc Tainted: G E 6.18.0-rc1+ #227 PREEMPT(none)
>>> [ 3950.751749] Tainted: [E]=UNSIGNED_MODULE
>>> [ 3950.755655] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 1.91 07/29/2022
>>> [ 3950.763797] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>>> [ 3950.770729] pc : acpi_os_write_memory+0x108/0x150
>>> [ 3950.775419] lr : acpi_os_write_memory+0x28/0x150
>>> [ 3950.780017] sp : ffff800093fbba40
>>> [ 3950.783319] x29: ffff800093fbba40 x28: 0000000000000000 x27: 0000000000000000
>>> [ 3950.790425] x26: 0000000000000002 x25: ffffffffffffffff x24: 000000403f20e400
>>> [ 3950.797530] x23: 0000000000000000 x22: 0000000000000008 x21: 000000000000ffff
>>> [ 3950.804635] x20: 0000000000000040 x19: 000000002f7d0018 x18: 0000000000000000
>>> [ 3950.811741] x17: 0000000000000000 x16: ffffae52d36ae5d0 x15: 000000001ba8e890
>>> [ 3950.818847] x14: 0000000000000000 x13: 0000000000000000 x12: 0000005fffffffff
>>> [ 3950.825952] x11: 0000000000000001 x10: ffff00400d761b90 x9 : ffffae52d365b198
>>> [ 3950.833058] x8 : 0000280000000000 x7 : 000000002f7d0018 x6 : ffffae52d5198548
>>> [ 3950.840164] x5 : 000000002f7d1000 x4 : 0000000000000018 x3 : ffff204016735060
>>> [ 3950.847269] x2 : 0000000000000040 x1 : 0000000000000000 x0 : ffff8000845bd018
>>> [ 3950.854376] Call trace:
>>> [ 3950.856814] acpi_os_write_memory+0x108/0x150 (P)
>>> [ 3950.861500] apei_write+0xb4/0xd0
>>> [ 3950.864806] apei_exec_write_register_value+0x88/0xc0
>>> [ 3950.869838] __apei_exec_run+0xac/0x120
>>> [ 3950.873659] __einj_error_inject+0x88/0x408 [einj]
>>> [ 3950.878434] einj_error_inject+0x168/0x1f0 [einj]
>>> [ 3950.883120] error_inject_set+0x48/0x60 [einj]
>>> [ 3950.887548] simple_attr_write_xsigned.constprop.0.isra.0+0x14c/0x1d0
>>> [ 3950.893964] simple_attr_write+0x1c/0x30
>>> [ 3950.897873] debugfs_attr_write+0x54/0xa0
>>> [ 3950.901870] vfs_write+0xc4/0x240
>>> [ 3950.905173] ksys_write+0x70/0x108
>>> [ 3950.908562] __arm64_sys_write+0x20/0x30
>>> [ 3950.912471] invoke_syscall+0x4c/0x110
>>> [ 3950.916207] el0_svc_common.constprop.0+0x44/0xe8
>>> [ 3950.920893] do_el0_svc+0x20/0x30
>>> [ 3950.924194] el0_svc+0x38/0x160
>>> [ 3950.927324] el0t_64_sync_handler+0x98/0xe0
>>> [ 3950.931491] el0t_64_sync+0x184/0x188
>>> [ 3950.935140] Code: 14000006 7101029f 54000221 d50332bf (f9000015)
>>> [ 3950.941210] ---[ end trace 0000000000000000 ]---
>>> [ 3950.945807] Kernel panic - not syncing: Oops: Fatal exception
>>>
>>> We need to fix it first.
>>
>> Hi shuai xue,
>>
>> Sorry for my late reply. Thank you for the review.
>> To clarify the issue:
>> This problem was introduced in v6.18-rc1 via a suspicious ARM64
>> memory mapping change [1]. I can reproduce the crash consistently
>> using the v6.18-rc1 kernel with this patch applied.
>>
>> Crucially, the crash disappears when the change is reverted — error
>> injection completes successfully without any kernel panic or oops.
>> This confirms that the ARM64 memory mapping change is the root cause.
>>
>> As noted in the original report, the change was reverted in v6.19-rc1, and
>> subsequent kernels (including v6.19-rc1 and later) are stable and do not
>> exhibit this problem.
>>
>> reproduce logs:
>> [ 216.347073] Unable to handle kernel write to read-only memory at virtual address ffff800084825018
>> ...
>> [ 216.475949] CPU: 75 UID: 0 PID: 11477 Comm: sh Kdump: loaded Not tainted 6.18.0-rc1+ #60 PREEMPT
>> [ 216.486561] Hardware name: Huawei TaiShan 2280 V2/BC82AMDD, BIOS 1.91 07/29/2022
>> [ 216.587297] Call trace:
>> [ 216.589904] acpi_os_write_memory+0x188/0x1c8 (P)
>> [ 216.594763] apei_write+0xcc/0xe8
>> [ 216.598238] apei_exec_write_register_value+0x90/0xd0
>> [ 216.603437] __apei_exec_run+0xb0/0x128
>> [ 216.607420] __einj_error_inject+0xac/0x450
>> [ 216.611750] einj_error_inject+0x19c/0x220
>> [ 216.615988] error_inject_set+0x4c/0x68
>> [ 216.619962] simple_attr_write_xsigned.constprop.0.isra.0+0xe8/0x1b0
>> [ 216.626445] simple_attr_write+0x20/0x38
>> [ 216.630502] debugfs_attr_write+0x58/0xa8
>> [ 216.634643] vfs_write+0xdc/0x408
>> [ 216.638088] ksys_write+0x78/0x118
>> [ 216.641610] __arm64_sys_write+0x24/0x38
>> [ 216.645648] invoke_syscall+0x50/0x120
>> [ 216.649510] el0_svc_common.constprop.0+0xc8/0xf0
>> [ 216.654318] do_el0_svc+0x24/0x38
>> [ 216.657742] el0_svc+0x38/0x150
>> [ 216.660996] el0t_64_sync_handler+0xa0/0xe8
>> [ 216.665286] el0t_64_sync+0x1ac/0x1b0
>> [ 216.669054] Code: d65f03c0 710102ff 540001e1 d50332bf (f9000295)
>> [ 216.675244] ---[ end trace 0000000000000000 ]---
>>
>> [1] https://lore.kernel.org/all/20251121224611.07efa95a@foz.lan/
>>
>> Best regards,
>> Junhao.
>
> Thanks for clarify the issue.
>
> Thanks.
> Shuai
>
> .
>
^ permalink raw reply
* Re: [PATCH v2] raid6: arm64: add SVE optimized implementation for syndrome generation
From: Mark Rutland @ 2026-03-24 10:04 UTC (permalink / raw)
To: Ard Biesheuvel, Christoph Hellwig, Demian Shulhan
Cc: Song Liu, Yu Kuai, Will Deacon, Catalin Marinas, broonie,
linux-arm-kernel, robin.murphy, Li Nan, linux-raid, linux-kernel
In-Reply-To: <f9bc0534-4b7a-4b14-974b-4d7811ccd899@app.fastmail.com>
On Tue, Mar 24, 2026 at 09:00:16AM +0100, Ard Biesheuvel wrote:
> On Wed, 18 Mar 2026, at 16:02, Demian Shulhan wrote:
> > Implement Scalable Vector Extension (SVE) optimized routines for RAID6
> > syndrome generation and recovery on ARM64.
> >
> > The SVE instruction set allows for variable vector lengths (from 128 to
> > 2048 bits), scaling automatically with the hardware capabilities. This
> > implementation handles arbitrary SVE vector lengths using the `cntb`
> > instruction to determine the runtime vector length.
> >
> > The implementation introduces `svex1`, `svex2`, and `svex4` algorithms.
> > The `svex4` algorithm utilizes loop unrolling by 4 blocks per iteration
> > and manual software pipelining (interleaving memory loads with XORs)
> > to minimize instruction dependency stalls and maximize CPU pipeline
> > utilization and memory bandwidth.
> >
> > Performance was tested on an AWS Graviton3 (Neoverse-V1) instance which
> > features 256-bit SVE vector length. The `svex4` implementation outperforms
> > the existing 128-bit `neonx4` baseline for syndrome generation:
> >
> > raid6: svex4 gen() 19688 MB/s
> ...
> > raid6: neonx4 gen() 19612 MB/s
>
> You're being very generous characterising a 0.3% speedup as 'outperforms'
>
> But the real problem here is that the kernel-mode SIMD API only
> supports NEON and not SVE, and preserves/restores only the 128-bit
> view on the NEON/SVE register file. So any context switch or softirq
> that uses kernel-mode SIMD too, and your SVE register values will get
> truncated.
Just to be a bit more explicit, since only the NEON register file is
saved:
* The vector registers will be truncated to 128-bit across
preemption or softirq.
* The predicates won't be saved/restored and will change arbitrarily
across preemption.
* The VL won't be saved/restored, and might change arbitrarily across
preemption.
* The VL to use hasn't been programmed, so performance might vary
arbitrarily even in the absence of preemption.
... so this isn't even safe on machines with (only) a 128-bit VL, and
there are big open design questions for the infrastructure we'd need.
> Once we encounter a good use case for SVE in the kernel, we might
> reconsider this, but as it stands, this patch should not be applied.
I agree.
Christoph, please do not pick this or any other in-kernel SVE patches.
They cannot function correctly without additional infrastructure.
Demian, for patches that use NEON/SVE/SME/etc, please Cc LAKML
(linux-arm-kernel@lists.infradead.org), so that folk familiar with ARM
see the patches.
Mark
> (leaving the reply untrimmed for the benefit of the cc'ees I added)
>
> > raid6: neonx2 gen() 16248 MB/s
> > raid6: neonx1 gen() 13591 MB/s
> > raid6: using algorithm svex4 gen() 19688 MB/s
> > raid6: .... xor() 11212 MB/s, rmw enabled
> > raid6: using neon recovery algorithm
> >
> > Note that for the recovery path (`xor_syndrome`), NEON may still be
> > selected dynamically by the algorithm benchmark, as the recovery
> > workload is heavily memory-bound.
> >
> > Signed-off-by: Demian Shulhan <demyansh@gmail.com>
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202603181940.cFwYmYoi-lkp@intel.com/
> > ---
> > include/linux/raid/pq.h | 3 +
> > lib/raid6/Makefile | 5 +
> > lib/raid6/algos.c | 5 +
> > lib/raid6/sve.c | 675 ++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 688 insertions(+)
> > create mode 100644 lib/raid6/sve.c
> >
> > diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
> > index 2467b3be15c9..787cc57aea9d 100644
> > --- a/include/linux/raid/pq.h
> > +++ b/include/linux/raid/pq.h
> > @@ -140,6 +140,9 @@ extern const struct raid6_calls raid6_neonx1;
> > extern const struct raid6_calls raid6_neonx2;
> > extern const struct raid6_calls raid6_neonx4;
> > extern const struct raid6_calls raid6_neonx8;
> > +extern const struct raid6_calls raid6_svex1;
> > +extern const struct raid6_calls raid6_svex2;
> > +extern const struct raid6_calls raid6_svex4;
> >
> > /* Algorithm list */
> > extern const struct raid6_calls * const raid6_algos[];
> > diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> > index 5be0a4e60ab1..6cdaa6f206fb 100644
> > --- a/lib/raid6/Makefile
> > +++ b/lib/raid6/Makefile
> > @@ -8,6 +8,7 @@ raid6_pq-$(CONFIG_X86) += recov_ssse3.o recov_avx2.o
> > mmx.o sse1.o sse2.o avx2.o
> > raid6_pq-$(CONFIG_ALTIVEC) += altivec1.o altivec2.o altivec4.o
> > altivec8.o \
> > vpermxor1.o vpermxor2.o vpermxor4.o
> > vpermxor8.o
> > raid6_pq-$(CONFIG_KERNEL_MODE_NEON) += neon.o neon1.o neon2.o neon4.o
> > neon8.o recov_neon.o recov_neon_inner.o
> > +raid6_pq-$(CONFIG_ARM64_SVE) += sve.o
> > raid6_pq-$(CONFIG_S390) += s390vx8.o recov_s390xc.o
> > raid6_pq-$(CONFIG_LOONGARCH) += loongarch_simd.o recov_loongarch_simd.o
> > raid6_pq-$(CONFIG_RISCV_ISA_V) += rvv.o recov_rvv.o
> > @@ -67,6 +68,10 @@ CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
> > CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
> > CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
> > CFLAGS_REMOVE_recov_neon_inner.o += $(CC_FLAGS_NO_FPU)
> > +
> > +CFLAGS_sve.o += $(CC_FLAGS_FPU)
> > +CFLAGS_REMOVE_sve.o += $(CC_FLAGS_NO_FPU)
> > +
> > targets += neon1.c neon2.c neon4.c neon8.c
> > $(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
> > $(call if_changed,unroll)
> > diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
> > index 799e0e5eac26..0ae73c3a4be3 100644
> > --- a/lib/raid6/algos.c
> > +++ b/lib/raid6/algos.c
> > @@ -66,6 +66,11 @@ const struct raid6_calls * const raid6_algos[] = {
> > &raid6_neonx2,
> > &raid6_neonx1,
> > #endif
> > +#ifdef CONFIG_ARM64_SVE
> > + &raid6_svex4,
> > + &raid6_svex2,
> > + &raid6_svex1,
> > +#endif
> > #ifdef CONFIG_LOONGARCH
> > #ifdef CONFIG_CPU_HAS_LASX
> > &raid6_lasx,
> > diff --git a/lib/raid6/sve.c b/lib/raid6/sve.c
> > new file mode 100644
> > index 000000000000..d52937f806d4
> > --- /dev/null
> > +++ b/lib/raid6/sve.c
> > @@ -0,0 +1,675 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * RAID-6 syndrome calculation using ARM SVE instructions
> > + */
> > +
> > +#include <linux/raid/pq.h>
> > +
> > +#ifdef __KERNEL__
> > +#include <asm/simd.h>
> > +#include <linux/cpufeature.h>
> > +#else
> > +#define scoped_ksimd()
> > +#define system_supports_sve() (1)
> > +#endif
> > +
> > +static void raid6_sve1_gen_syndrome_real(int disks, unsigned long
> > bytes, void **ptrs)
> > +{
> > + u8 **dptr = (u8 **)ptrs;
> > + u8 *p, *q;
> > + long z0 = disks - 3;
> > +
> > + p = dptr[z0 + 1];
> > + q = dptr[z0 + 2];
> > +
> > + asm volatile(
> > + ".arch armv8.2-a+sve\n"
> > + "ptrue p0.b\n"
> > + "cntb x3\n"
> > + "mov w4, #0x1d\n"
> > + "dup z4.b, w4\n"
> > + "mov x5, #0\n"
> > +
> > + "0:\n"
> > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > + "ld1b z0.b, p0/z, [x6, x5]\n"
> > + "mov z1.d, z0.d\n"
> > +
> > + "mov w7, %w[z0]\n"
> > + "sub w7, w7, #1\n"
> > +
> > + "1:\n"
> > + "cmp w7, #0\n"
> > + "blt 2f\n"
> > +
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > +
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + "sxtw x8, w7\n"
> > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > +
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z0.d, z0.d, z2.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 1b\n"
> > + "2:\n"
> > +
> > + "st1b z0.b, p0, [%[p], x5]\n"
> > + "st1b z1.b, p0, [%[q], x5]\n"
> > +
> > + "add x5, x5, x3\n"
> > + "cmp x5, %[bytes]\n"
> > + "blt 0b\n"
> > + :
> > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > + [p] "r" (p), [q] "r" (q)
> > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > + "z0", "z1", "z2", "z3", "z4"
> > + );
> > +}
> > +
> > +static void raid6_sve1_xor_syndrome_real(int disks, int start, int
> > stop,
> > + unsigned long bytes, void **ptrs)
> > +{
> > + u8 **dptr = (u8 **)ptrs;
> > + u8 *p, *q;
> > + long z0 = stop;
> > +
> > + p = dptr[disks - 2];
> > + q = dptr[disks - 1];
> > +
> > + asm volatile(
> > + ".arch armv8.2-a+sve\n"
> > + "ptrue p0.b\n"
> > + "cntb x3\n"
> > + "mov w4, #0x1d\n"
> > + "dup z4.b, w4\n"
> > + "mov x5, #0\n"
> > +
> > + "0:\n"
> > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > + "ld1b z1.b, p0/z, [x6, x5]\n"
> > + "ld1b z0.b, p0/z, [%[p], x5]\n"
> > + "eor z0.d, z0.d, z1.d\n"
> > +
> > + "mov w7, %w[z0]\n"
> > + "sub w7, w7, #1\n"
> > +
> > + "1:\n"
> > + "cmp w7, %w[start]\n"
> > + "blt 2f\n"
> > +
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + "sxtw x8, w7\n"
> > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > +
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z0.d, z0.d, z2.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 1b\n"
> > + "2:\n"
> > +
> > + "mov w7, %w[start]\n"
> > + "sub w7, w7, #1\n"
> > + "3:\n"
> > + "cmp w7, #0\n"
> > + "blt 4f\n"
> > +
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 3b\n"
> > + "4:\n"
> > +
> > + "ld1b z2.b, p0/z, [%[q], x5]\n"
> > + "eor z1.d, z1.d, z2.d\n"
> > +
> > + "st1b z0.b, p0, [%[p], x5]\n"
> > + "st1b z1.b, p0, [%[q], x5]\n"
> > +
> > + "add x5, x5, x3\n"
> > + "cmp x5, %[bytes]\n"
> > + "blt 0b\n"
> > + :
> > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > + [p] "r" (p), [q] "r" (q), [start] "r" (start)
> > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > + "z0", "z1", "z2", "z3", "z4"
> > + );
> > +}
> > +
> > +static void raid6_sve2_gen_syndrome_real(int disks, unsigned long
> > bytes, void **ptrs)
> > +{
> > + u8 **dptr = (u8 **)ptrs;
> > + u8 *p, *q;
> > + long z0 = disks - 3;
> > +
> > + p = dptr[z0 + 1];
> > + q = dptr[z0 + 2];
> > +
> > + asm volatile(
> > + ".arch armv8.2-a+sve\n"
> > + "ptrue p0.b\n"
> > + "cntb x3\n"
> > + "mov w4, #0x1d\n"
> > + "dup z4.b, w4\n"
> > + "mov x5, #0\n"
> > +
> > + "0:\n"
> > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > + "ld1b z0.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z5.b, p0/z, [x6, x8]\n"
> > + "mov z1.d, z0.d\n"
> > + "mov z6.d, z5.d\n"
> > +
> > + "mov w7, %w[z0]\n"
> > + "sub w7, w7, #1\n"
> > +
> > + "1:\n"
> > + "cmp w7, #0\n"
> > + "blt 2f\n"
> > +
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + "mov z8.d, z6.d\n"
> > + "asr z8.b, p0/m, z8.b, #7\n"
> > + "lsl z6.b, p0/m, z6.b, #1\n"
> > + "and z8.d, z8.d, z4.d\n"
> > + "eor z6.d, z6.d, z8.d\n"
> > +
> > + "sxtw x8, w7\n"
> > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > +
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z0.d, z0.d, z2.d\n"
> > +
> > + "eor z6.d, z6.d, z7.d\n"
> > + "eor z5.d, z5.d, z7.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 1b\n"
> > + "2:\n"
> > +
> > + "st1b z0.b, p0, [%[p], x5]\n"
> > + "st1b z1.b, p0, [%[q], x5]\n"
> > + "add x8, x5, x3\n"
> > + "st1b z5.b, p0, [%[p], x8]\n"
> > + "st1b z6.b, p0, [%[q], x8]\n"
> > +
> > + "add x5, x5, x3\n"
> > + "add x5, x5, x3\n"
> > + "cmp x5, %[bytes]\n"
> > + "blt 0b\n"
> > + :
> > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > + [p] "r" (p), [q] "r" (q)
> > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > + "z0", "z1", "z2", "z3", "z4",
> > + "z5", "z6", "z7", "z8"
> > + );
> > +}
> > +
> > +static void raid6_sve2_xor_syndrome_real(int disks, int start, int
> > stop,
> > + unsigned long bytes, void **ptrs)
> > +{
> > + u8 **dptr = (u8 **)ptrs;
> > + u8 *p, *q;
> > + long z0 = stop;
> > +
> > + p = dptr[disks - 2];
> > + q = dptr[disks - 1];
> > +
> > + asm volatile(
> > + ".arch armv8.2-a+sve\n"
> > + "ptrue p0.b\n"
> > + "cntb x3\n"
> > + "mov w4, #0x1d\n"
> > + "dup z4.b, w4\n"
> > + "mov x5, #0\n"
> > +
> > + "0:\n"
> > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > + "ld1b z1.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z6.b, p0/z, [x6, x8]\n"
> > +
> > + "ld1b z0.b, p0/z, [%[p], x5]\n"
> > + "ld1b z5.b, p0/z, [%[p], x8]\n"
> > +
> > + "eor z0.d, z0.d, z1.d\n"
> > + "eor z5.d, z5.d, z6.d\n"
> > +
> > + "mov w7, %w[z0]\n"
> > + "sub w7, w7, #1\n"
> > +
> > + "1:\n"
> > + "cmp w7, %w[start]\n"
> > + "blt 2f\n"
> > +
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + "mov z8.d, z6.d\n"
> > + "asr z8.b, p0/m, z8.b, #7\n"
> > + "lsl z6.b, p0/m, z6.b, #1\n"
> > + "and z8.d, z8.d, z4.d\n"
> > + "eor z6.d, z6.d, z8.d\n"
> > +
> > + "sxtw x8, w7\n"
> > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > +
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z0.d, z0.d, z2.d\n"
> > +
> > + "eor z6.d, z6.d, z7.d\n"
> > + "eor z5.d, z5.d, z7.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 1b\n"
> > + "2:\n"
> > +
> > + "mov w7, %w[start]\n"
> > + "sub w7, w7, #1\n"
> > + "3:\n"
> > + "cmp w7, #0\n"
> > + "blt 4f\n"
> > +
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + "mov z8.d, z6.d\n"
> > + "asr z8.b, p0/m, z8.b, #7\n"
> > + "lsl z6.b, p0/m, z6.b, #1\n"
> > + "and z8.d, z8.d, z4.d\n"
> > + "eor z6.d, z6.d, z8.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 3b\n"
> > + "4:\n"
> > +
> > + "ld1b z2.b, p0/z, [%[q], x5]\n"
> > + "eor z1.d, z1.d, z2.d\n"
> > + "st1b z0.b, p0, [%[p], x5]\n"
> > + "st1b z1.b, p0, [%[q], x5]\n"
> > +
> > + "add x8, x5, x3\n"
> > + "ld1b z7.b, p0/z, [%[q], x8]\n"
> > + "eor z6.d, z6.d, z7.d\n"
> > + "st1b z5.b, p0, [%[p], x8]\n"
> > + "st1b z6.b, p0, [%[q], x8]\n"
> > +
> > + "add x5, x5, x3\n"
> > + "add x5, x5, x3\n"
> > + "cmp x5, %[bytes]\n"
> > + "blt 0b\n"
> > + :
> > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > + [p] "r" (p), [q] "r" (q), [start] "r" (start)
> > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > + "z0", "z1", "z2", "z3", "z4",
> > + "z5", "z6", "z7", "z8"
> > + );
> > +}
> > +
> > +static void raid6_sve4_gen_syndrome_real(int disks, unsigned long
> > bytes, void **ptrs)
> > +{
> > + u8 **dptr = (u8 **)ptrs;
> > + u8 *p, *q;
> > + long z0 = disks - 3;
> > +
> > + p = dptr[z0 + 1];
> > + q = dptr[z0 + 2];
> > +
> > + asm volatile(
> > + ".arch armv8.2-a+sve\n"
> > + "ptrue p0.b\n"
> > + "cntb x3\n"
> > + "mov w4, #0x1d\n"
> > + "dup z4.b, w4\n"
> > + "mov x5, #0\n"
> > +
> > + "0:\n"
> > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > + "ld1b z0.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z5.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z10.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z15.b, p0/z, [x6, x8]\n"
> > +
> > + "mov z1.d, z0.d\n"
> > + "mov z6.d, z5.d\n"
> > + "mov z11.d, z10.d\n"
> > + "mov z16.d, z15.d\n"
> > +
> > + "mov w7, %w[z0]\n"
> > + "sub w7, w7, #1\n"
> > +
> > + "1:\n"
> > + "cmp w7, #0\n"
> > + "blt 2f\n"
> > +
> > + // software pipelining: load data early
> > + "sxtw x8, w7\n"
> > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z12.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z17.b, p0/z, [x6, x8]\n"
> > +
> > + // math block 1
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z0.d, z0.d, z2.d\n"
> > +
> > + // math block 2
> > + "mov z8.d, z6.d\n"
> > + "asr z8.b, p0/m, z8.b, #7\n"
> > + "lsl z6.b, p0/m, z6.b, #1\n"
> > + "and z8.d, z8.d, z4.d\n"
> > + "eor z6.d, z6.d, z8.d\n"
> > + "eor z6.d, z6.d, z7.d\n"
> > + "eor z5.d, z5.d, z7.d\n"
> > +
> > + // math block 3
> > + "mov z13.d, z11.d\n"
> > + "asr z13.b, p0/m, z13.b, #7\n"
> > + "lsl z11.b, p0/m, z11.b, #1\n"
> > + "and z13.d, z13.d, z4.d\n"
> > + "eor z11.d, z11.d, z13.d\n"
> > + "eor z11.d, z11.d, z12.d\n"
> > + "eor z10.d, z10.d, z12.d\n"
> > +
> > + // math block 4
> > + "mov z18.d, z16.d\n"
> > + "asr z18.b, p0/m, z18.b, #7\n"
> > + "lsl z16.b, p0/m, z16.b, #1\n"
> > + "and z18.d, z18.d, z4.d\n"
> > + "eor z16.d, z16.d, z18.d\n"
> > + "eor z16.d, z16.d, z17.d\n"
> > + "eor z15.d, z15.d, z17.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 1b\n"
> > + "2:\n"
> > +
> > + "st1b z0.b, p0, [%[p], x5]\n"
> > + "st1b z1.b, p0, [%[q], x5]\n"
> > + "add x8, x5, x3\n"
> > + "st1b z5.b, p0, [%[p], x8]\n"
> > + "st1b z6.b, p0, [%[q], x8]\n"
> > + "add x8, x8, x3\n"
> > + "st1b z10.b, p0, [%[p], x8]\n"
> > + "st1b z11.b, p0, [%[q], x8]\n"
> > + "add x8, x8, x3\n"
> > + "st1b z15.b, p0, [%[p], x8]\n"
> > + "st1b z16.b, p0, [%[q], x8]\n"
> > +
> > + "add x8, x3, x3\n"
> > + "add x5, x5, x8, lsl #1\n"
> > + "cmp x5, %[bytes]\n"
> > + "blt 0b\n"
> > + :
> > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > + [p] "r" (p), [q] "r" (q)
> > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > + "z0", "z1", "z2", "z3", "z4",
> > + "z5", "z6", "z7", "z8",
> > + "z10", "z11", "z12", "z13",
> > + "z15", "z16", "z17", "z18"
> > + );
> > +}
> > +
> > +static void raid6_sve4_xor_syndrome_real(int disks, int start, int
> > stop,
> > + unsigned long bytes, void **ptrs)
> > +{
> > + u8 **dptr = (u8 **)ptrs;
> > + u8 *p, *q;
> > + long z0 = stop;
> > +
> > + p = dptr[disks - 2];
> > + q = dptr[disks - 1];
> > +
> > + asm volatile(
> > + ".arch armv8.2-a+sve\n"
> > + "ptrue p0.b\n"
> > + "cntb x3\n"
> > + "mov w4, #0x1d\n"
> > + "dup z4.b, w4\n"
> > + "mov x5, #0\n"
> > +
> > + "0:\n"
> > + "ldr x6, [%[dptr], %[z0], lsl #3]\n"
> > + "ld1b z1.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z6.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z11.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z16.b, p0/z, [x6, x8]\n"
> > +
> > + "ld1b z0.b, p0/z, [%[p], x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z5.b, p0/z, [%[p], x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z10.b, p0/z, [%[p], x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z15.b, p0/z, [%[p], x8]\n"
> > +
> > + "eor z0.d, z0.d, z1.d\n"
> > + "eor z5.d, z5.d, z6.d\n"
> > + "eor z10.d, z10.d, z11.d\n"
> > + "eor z15.d, z15.d, z16.d\n"
> > +
> > + "mov w7, %w[z0]\n"
> > + "sub w7, w7, #1\n"
> > +
> > + "1:\n"
> > + "cmp w7, %w[start]\n"
> > + "blt 2f\n"
> > +
> > + // software pipelining: load data early
> > + "sxtw x8, w7\n"
> > + "ldr x6, [%[dptr], x8, lsl #3]\n"
> > + "ld1b z2.b, p0/z, [x6, x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z7.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z12.b, p0/z, [x6, x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z17.b, p0/z, [x6, x8]\n"
> > +
> > + // math block 1
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z0.d, z0.d, z2.d\n"
> > +
> > + // math block 2
> > + "mov z8.d, z6.d\n"
> > + "asr z8.b, p0/m, z8.b, #7\n"
> > + "lsl z6.b, p0/m, z6.b, #1\n"
> > + "and z8.d, z8.d, z4.d\n"
> > + "eor z6.d, z6.d, z8.d\n"
> > + "eor z6.d, z6.d, z7.d\n"
> > + "eor z5.d, z5.d, z7.d\n"
> > +
> > + // math block 3
> > + "mov z13.d, z11.d\n"
> > + "asr z13.b, p0/m, z13.b, #7\n"
> > + "lsl z11.b, p0/m, z11.b, #1\n"
> > + "and z13.d, z13.d, z4.d\n"
> > + "eor z11.d, z11.d, z13.d\n"
> > + "eor z11.d, z11.d, z12.d\n"
> > + "eor z10.d, z10.d, z12.d\n"
> > +
> > + // math block 4
> > + "mov z18.d, z16.d\n"
> > + "asr z18.b, p0/m, z18.b, #7\n"
> > + "lsl z16.b, p0/m, z16.b, #1\n"
> > + "and z18.d, z18.d, z4.d\n"
> > + "eor z16.d, z16.d, z18.d\n"
> > + "eor z16.d, z16.d, z17.d\n"
> > + "eor z15.d, z15.d, z17.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 1b\n"
> > + "2:\n"
> > +
> > + "mov w7, %w[start]\n"
> > + "sub w7, w7, #1\n"
> > + "3:\n"
> > + "cmp w7, #0\n"
> > + "blt 4f\n"
> > +
> > + // math block 1
> > + "mov z3.d, z1.d\n"
> > + "asr z3.b, p0/m, z3.b, #7\n"
> > + "lsl z1.b, p0/m, z1.b, #1\n"
> > + "and z3.d, z3.d, z4.d\n"
> > + "eor z1.d, z1.d, z3.d\n"
> > +
> > + // math block 2
> > + "mov z8.d, z6.d\n"
> > + "asr z8.b, p0/m, z8.b, #7\n"
> > + "lsl z6.b, p0/m, z6.b, #1\n"
> > + "and z8.d, z8.d, z4.d\n"
> > + "eor z6.d, z6.d, z8.d\n"
> > +
> > + // math block 3
> > + "mov z13.d, z11.d\n"
> > + "asr z13.b, p0/m, z13.b, #7\n"
> > + "lsl z11.b, p0/m, z11.b, #1\n"
> > + "and z13.d, z13.d, z4.d\n"
> > + "eor z11.d, z11.d, z13.d\n"
> > +
> > + // math block 4
> > + "mov z18.d, z16.d\n"
> > + "asr z18.b, p0/m, z18.b, #7\n"
> > + "lsl z16.b, p0/m, z16.b, #1\n"
> > + "and z18.d, z18.d, z4.d\n"
> > + "eor z16.d, z16.d, z18.d\n"
> > +
> > + "sub w7, w7, #1\n"
> > + "b 3b\n"
> > + "4:\n"
> > +
> > + // Load q and XOR
> > + "ld1b z2.b, p0/z, [%[q], x5]\n"
> > + "add x8, x5, x3\n"
> > + "ld1b z7.b, p0/z, [%[q], x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z12.b, p0/z, [%[q], x8]\n"
> > + "add x8, x8, x3\n"
> > + "ld1b z17.b, p0/z, [%[q], x8]\n"
> > +
> > + "eor z1.d, z1.d, z2.d\n"
> > + "eor z6.d, z6.d, z7.d\n"
> > + "eor z11.d, z11.d, z12.d\n"
> > + "eor z16.d, z16.d, z17.d\n"
> > +
> > + // Store results
> > + "st1b z0.b, p0, [%[p], x5]\n"
> > + "st1b z1.b, p0, [%[q], x5]\n"
> > + "add x8, x5, x3\n"
> > + "st1b z5.b, p0, [%[p], x8]\n"
> > + "st1b z6.b, p0, [%[q], x8]\n"
> > + "add x8, x8, x3\n"
> > + "st1b z10.b, p0, [%[p], x8]\n"
> > + "st1b z11.b, p0, [%[q], x8]\n"
> > + "add x8, x8, x3\n"
> > + "st1b z15.b, p0, [%[p], x8]\n"
> > + "st1b z16.b, p0, [%[q], x8]\n"
> > +
> > + "add x8, x3, x3\n"
> > + "add x5, x5, x8, lsl #1\n"
> > + "cmp x5, %[bytes]\n"
> > + "blt 0b\n"
> > + :
> > + : [dptr] "r" (dptr), [z0] "r" (z0), [bytes] "r" (bytes),
> > + [p] "r" (p), [q] "r" (q), [start] "r" (start)
> > + : "memory", "p0", "x3", "x4", "x5", "x6", "x7", "x8",
> > + "z0", "z1", "z2", "z3", "z4",
> > + "z5", "z6", "z7", "z8",
> > + "z10", "z11", "z12", "z13",
> > + "z15", "z16", "z17", "z18"
> > + );
> > +}
> > +
> > +#define RAID6_SVE_WRAPPER(_n) \
> > + static void raid6_sve ## _n ## _gen_syndrome(int disks, \
> > + size_t bytes, void **ptrs) \
> > + { \
> > + scoped_ksimd() \
> > + raid6_sve ## _n ## _gen_syndrome_real(disks, \
> > + (unsigned long)bytes, ptrs); \
> > + } \
> > + static void raid6_sve ## _n ## _xor_syndrome(int disks, \
> > + int start, int stop, \
> > + size_t bytes, void **ptrs) \
> > + { \
> > + scoped_ksimd() \
> > + raid6_sve ## _n ## _xor_syndrome_real(disks, \
> > + start, stop, (unsigned long)bytes, ptrs);\
> > + } \
> > + struct raid6_calls const raid6_svex ## _n = { \
> > + raid6_sve ## _n ## _gen_syndrome, \
> > + raid6_sve ## _n ## _xor_syndrome, \
> > + raid6_have_sve, \
> > + "svex" #_n, \
> > + 0 \
> > + }
> > +
> > +static int raid6_have_sve(void)
> > +{
> > + return system_supports_sve();
> > +}
> > +
> > +RAID6_SVE_WRAPPER(1);
> > +RAID6_SVE_WRAPPER(2);
> > +RAID6_SVE_WRAPPER(4);
> > --
> > 2.43.0
^ permalink raw reply
* [PATCH net-next 0/2] net: stmmac: remove unused and unimplemented AXI properties
From: Russell King (Oracle) @ 2026-03-24 10:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Conor Dooley, David S. Miller,
devicetree, Eric Dumazet, Giuseppe Cavallaro, Jakub Kicinski,
Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel, linux-stm32,
netdev, Paolo Abeni, Rob Herring, Yao Zi
commit afea03656add ("stmmac: rework DMA bus setting and introduce new
platform AXI structure") added support for parsing all the stmmac AXI
attributes, and added code to set most of the appropriate register bits
with three exceptions:
snps,kbbe
snps,mb
snps,rb
These were parsed by the driver, but the result of parsing was never
used by any of the cores.
Moreover, no DTS in the kernel makes use of these properties.
Thus, it doesn't make sense for the driver to parse these, so let's
remove them. Also remove them from the DT binding document.
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 18 ------------------
drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ---
include/linux/stmmac.h | 3 ---
4 files changed, 25 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH net-next 1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
From: Russell King (Oracle) @ 2026-03-24 10:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Conor Dooley, David S. Miller,
devicetree, Eric Dumazet, Giuseppe Cavallaro, Jakub Kicinski,
Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel, linux-stm32,
netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <acJh4z3pRKkeaFbR@shell.armlinux.org.uk>
axi_kbbe, axi_mb and axi_rb are all written, but nothing ever reads
their values. Remove the code that sets these and the struct members.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 ---
include/linux/stmmac.h | 3 ---
3 files changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
index d245546b90db..02c786ce5dd4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-motorcomm.c
@@ -231,7 +231,6 @@ motorcomm_default_plat_data(struct pci_dev *pdev)
plat->axi->axi_wr_osr_lmt = 1;
plat->axi->axi_rd_osr_lmt = 1;
- plat->axi->axi_mb = true;
plat->axi->axi_blen_regval = DMA_AXI_BLEN4 | DMA_AXI_BLEN8 |
DMA_AXI_BLEN16 | DMA_AXI_BLEN32;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 545b8a3425eb..5cae2aa72906 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -109,10 +109,7 @@ static struct stmmac_axi *stmmac_axi_setup(struct platform_device *pdev)
axi->axi_lpi_en = of_property_read_bool(np, "snps,lpi_en");
axi->axi_xit_frm = of_property_read_bool(np, "snps,xit_frm");
- axi->axi_kbbe = of_property_read_bool(np, "snps,kbbe");
axi->axi_fb = of_property_read_bool(np, "snps,fb");
- axi->axi_mb = of_property_read_bool(np, "snps,mb");
- axi->axi_rb = of_property_read_bool(np, "snps,rb");
if (of_property_read_u32(np, "snps,wr_osr_lmt", &axi->axi_wr_osr_lmt))
axi->axi_wr_osr_lmt = 1;
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 5b2bece81448..eaaee329ef9d 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -133,10 +133,7 @@ struct stmmac_axi {
u32 axi_blen_regval;
bool axi_lpi_en;
bool axi_xit_frm;
- bool axi_kbbe;
bool axi_fb;
- bool axi_mb;
- bool axi_rb;
};
struct stmmac_rxq_cfg {
--
2.47.3
^ permalink raw reply related
* [PATCH net-next 2/2] dt-bindings: remove unimplemented AXI snps,kbbe snps,mb and snps,rb
From: Russell King (Oracle) @ 2026-03-24 10:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, Conor Dooley, David S. Miller,
devicetree, Eric Dumazet, Giuseppe Cavallaro, Jakub Kicinski,
Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel, linux-stm32,
netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <acJh4z3pRKkeaFbR@shell.armlinux.org.uk>
Remove the AXI snps,kbbe snps,mb and snps,rb properties as they have
not been used, and although the driver parses these, the code hasn't
ever used the parsed result. This parsing has now been removed.
These were introduced by commit afea03656add ("stmmac: rework DMA bus
setting and introduce new platform AXI structure").
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 98ebb6276bc6..6d4afd824418 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -203,11 +203,8 @@ title: Synopsys DesignWare MAC
* snps,xit_frm, unlock on WoL
* snps,wr_osr_lmt, max write outstanding req. limit
* snps,rd_osr_lmt, max read outstanding req. limit
- * snps,kbbe, do not cross 1KiB boundary.
* snps,blen, this is a vector of supported burst length.
* snps,fb, fixed-burst
- * snps,mb, mixed-burst
- * snps,rb, rebuild INCRx Burst
snps,mtl-rx-config:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -587,11 +584,6 @@ title: Synopsys DesignWare MAC
description:
max read outstanding req. limit
- snps,kbbe:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- do not cross 1KiB boundary.
-
snps,blen:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
@@ -604,16 +596,6 @@ title: Synopsys DesignWare MAC
description:
fixed-burst
- snps,mb:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- mixed-burst
-
- snps,rb:
- $ref: /schemas/types.yaml#/definitions/flag
- description:
- rebuild INCRx Burst
-
required:
- compatible
- reg
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] arm64: vdso: fix AArch32 compat init allocation leaks
From: Thomas Weißschuh @ 2026-03-24 10:09 UTC (permalink / raw)
To: Will Deacon
Cc: Osama Abdelkader, Catalin Marinas, Kees Cook, Andrew Morton,
Liam R. Howlett, Jeff Xu, linux-arm-kernel, linux-kernel
In-Reply-To: <acJgc9EVRJJOVM0S@willie-the-truck>
On Tue, Mar 24, 2026 at 09:59:15AM +0000, Will Deacon wrote:
> On Mon, Mar 23, 2026 at 10:41:16PM +0100, Osama Abdelkader wrote:
> > aarch32_alloc_vdso_pages() allocates the AA32 vdso pagelist, the compat
> > sigpage, then the kuser vectors page. If aarch32_alloc_sigpage() or
> > aarch32_alloc_kuser_vdso_page() fails, earlier allocations were not freed.
>
> But why should they be freed? The vectors, sigpage and vdso are
> independent from one another, so we can limp along with whatever we
> managed to allocate. I'm not sure how far we'll get, mind, if single
> page allocations are failing at initcall time...
In the core vDSO datastore we just panic() if the allocation fails.
(See tip/timers/vdso for the currentl implementation)
The same should work for the architecture-specific bits.
Also I am wondering again why the return values of initcalls are ignored.
Thomas
^ permalink raw reply
* Re: [PATCH v6 00/40] arm_mpam: Add KVM/arm64 and resctrl glue code
From: Ben Horgan @ 2026-03-24 10:09 UTC (permalink / raw)
To: Gavin Shan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc
In-Reply-To: <71f9ac1e-9f5a-4f12-807b-bbe0803f99e7@redhat.com>
Hi Gavin,
On 3/23/26 04:41, Gavin Shan wrote:
> * # Be careful, this email looks suspicious; * Out of Character: The sender is exhibiting a significant deviation from
> their usual behavior, this may indicate that their account has been compromised. Be extra cautious before opening links
> or attachments. *
> On 3/14/26 12:45 AM, Ben Horgan wrote:
>> This version of the mpam missing pieces series sees a couple of things
>> dropped or hidden. Memory bandwith utilization with free-running counters
>> is dropped in preference of just always using 'mbm_event' mode (ABMC
>> emulation) which simplifies the code and allows for, in the future,
>> filtering by read/write traffic. So, for the interim, there is no memory
>> bandwidth utilization support. CDP is hidden behind config expert as
>> remount of resctrl fs could potentially lead to out of range PARTIDs being
>> used and the fix requires a change in fs/resctrl. The setting of MPAM2_EL2
>> (for pkvm/nvhe) is dropped as too expensive a write for not much value.
>>
>> There are a couple of 'fixes' at the start of the series which address
>> problems in the base driver but are only user visible due to this series.
>>
>> Changelogs in patches
>>
>> Thanks for all the reviewing and testing so far. Just a bit more to get this
>> over the line.
>>
>> There is a small build conflict with the MPAM abmc precursors series [1], which
>> alters some of the resctrl arch hooks. I will shortly be posting a respin
>> of that too.
>>
>> [1] https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/
>>
>> From James' cover letter:
>>
>> This is the missing piece to make MPAM usable resctrl in user-space. This has
>> shed its debugfs code and the read/write 'event configuration' for the monitors
>> to make the series smaller.
>>
>> This adds the arch code and KVM support first. I anticipate the whole thing
>> going via arm64, but if goes via tip instead, the an immutable branch with those
>> patches should be easy to do.
>>
>> Generally the resctrl glue code works by picking what MPAM features it can expose
>> from the MPAM drive, then configuring the structs that back the resctrl helpers.
>> If your platform is sufficiently Xeon shaped, you should be able to get L2/L3 CPOR
>> bitmaps exposed via resctrl. CSU counters work if they are on/after the L3. MBWU
>> counters are considerably more hairy, and depend on hueristics around the topology,
>> and a bunch of stuff trying to emulate ABMC.
>> If it didn't pick what you wanted it to, please share the debug messages produced
>> when enabling dynamic debug and booting with:
>> | dyndbg="file mpam_resctrl.c +pl"
>>
>> I've not found a platform that can test all the behaviours around the monitors,
>> so this is where I'd expect the most bugs.
>>
>> The MPAM spec that describes all the system and MMIO registers can be found here:
>> https://developer.arm.com/documentation/ddi0598/db/?lang=en
>> (Ignored the 'RETIRED' warning - that is just arm moving the documentation around.
>> This document has the best overview)
>>
>>
>> Based on v7.0-rc3
>>
>> The series can be retrieved from:
>> https://gitlab.arm.com/linux-arm/linux-bh.git mpam_resctrl_glue_v6
>>
>
> [...]
>
> Retested this series on NVidia's grace-hopper machine where L3 cache partitioning
> and MBW (soft) limiting worked as expected. Besides, The L3 cache monitor counters
> are increased as more cache usage is observed.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
Thanks for testing and all the reviews.
Ben
>
> Thanks,
> Gavin
>
>
^ permalink raw reply
* Re: [PATCH] arm64: vdso: fix AArch32 compat init allocation leaks
From: Will Deacon @ 2026-03-24 10:14 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Osama Abdelkader, Catalin Marinas, Kees Cook, Andrew Morton,
Liam R. Howlett, Jeff Xu, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324110512-7a00b224-8c48-445b-93f3-dd9b7a07d3cd@linutronix.de>
On Tue, Mar 24, 2026 at 11:09:12AM +0100, Thomas Weißschuh wrote:
> On Tue, Mar 24, 2026 at 09:59:15AM +0000, Will Deacon wrote:
> > On Mon, Mar 23, 2026 at 10:41:16PM +0100, Osama Abdelkader wrote:
> > > aarch32_alloc_vdso_pages() allocates the AA32 vdso pagelist, the compat
> > > sigpage, then the kuser vectors page. If aarch32_alloc_sigpage() or
> > > aarch32_alloc_kuser_vdso_page() fails, earlier allocations were not freed.
> >
> > But why should they be freed? The vectors, sigpage and vdso are
> > independent from one another, so we can limp along with whatever we
> > managed to allocate. I'm not sure how far we'll get, mind, if single
> > page allocations are failing at initcall time...
>
> In the core vDSO datastore we just panic() if the allocation fails.
> (See tip/timers/vdso for the currentl implementation)
> The same should work for the architecture-specific bits.
I think we should just leave the code as-is tbh unless there's an actual
issue here.
Will
^ permalink raw reply
* [PATCH v2 0/2] Make TPS65219 poweroff handler conditional
From: Akashdeep Kaur @ 2026-03-24 10:14 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
This series makes the TPS65219 PMIC poweroff handler registration
conditional based on device tree configuration, following standard
kernel patterns.
Currently, the TPS65219 driver unconditionally registers as the system
poweroff handler. This creates conflicts on platforms where alternative
poweroff mechanisms (such as TF-A firmware or other power controllers)
should handle system shutdown instead.
The standard kernel approach is to use the "system-power-controller"
device tree property to explicitly designate which component is
responsible for system poweroff operations.
Patch 1: Add "system-power-controller" property to AM62-LP-SK device
tree, explicitly designating the TPS65219 PMIC as the system
power controller for this platform. This property was missing
only on AM62-LP-SK among all in-tree TPS65219-based devices.
Patch 2: Update TPS65219 driver to only register poweroff handler when
"system-power-controller" property is present. This allows
other systems using this PMIC to use alternative poweroff
mechanisms.
Impact:
- AM62-LP-SK: No functional change (property added, handler still
registers)
- Other TPS65219-based systems: Poweroff handler registration becomes
opt-in via DT property
Tested on AM62-LP-SK - system poweroff works correctly.
Changes in v2:
- Addressed review feedback by removing comment on self explanatory code
- Link to v1: https://lore.kernel.org/all/20260310111846.1084623-1-a-kaur@ti.com/
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
Akashdeep Kaur (2):
arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
mfd: tps65219: Make poweroff handler conditional on
system-power-controller
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
drivers/mfd/tps65219.c | 14 ++++++++------
2 files changed, 9 insertions(+), 6 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3 5/5] KVM: arm64: Add SMC hook for SME dvmsync erratum
From: Vincent Donnefort @ 2026-03-24 10:14 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arm-kernel, Will Deacon, Marc Zyngier, Oliver Upton,
Lorenzo Pieralisi, Sudeep Holla, James Morse, Mark Rutland,
Mark Brown, kvmarm
In-Reply-To: <20260323162408.4163113-6-catalin.marinas@arm.com>
On Mon, Mar 23, 2026 at 04:24:05PM +0000, Catalin Marinas wrote:
> From: James Morse <james.morse@arm.com>
>
> C1-Pro cores with SME have an erratum where TLBI+DSB does not complete
> all outstanding SME accesses. Instead a DSB needs to be executed on the
> affecteed CPUs. The implication is pages cannot be unmapped from the
> host stage2 then provided to the guest. Host SME accesses may occur
> after this point.
>
> This erratum breaks pKVM's guarantees, and the workaround is hard to
> implement as EL2 and EL1 share a security state meaning EL1 can mask
> IPI sent by EL2, leading to interrupt blackouts.
>
> Instead, do this in EL3. This has the advantage of a separate security
> state, meaning lower EL cannot mask the IPI. It is also simpler for EL3
> to know about CPUs that are off or in PSCI's CPU_SUSPEND.
>
> Add the needed hook.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@kernel.org>
In case this goes in before Will's p-guest series and with just a small comment
below:
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 17 +++++++++++++++++
> include/linux/arm-smccc.h | 6 ++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 38f66a56a766..ef8afbdd421b 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -5,6 +5,8 @@
> */
>
> #include <linux/kvm_host.h>
> +#include <linux/arm-smccc.h>
> +
> #include <asm/kvm_emulate.h>
> #include <asm/kvm_hyp.h>
> #include <asm/kvm_mmu.h>
> @@ -28,6 +30,15 @@ static struct hyp_pool host_s2_pool;
> static DEFINE_PER_CPU(struct pkvm_hyp_vm *, __current_vm);
> #define current_vm (*this_cpu_ptr(&__current_vm))
>
> +static void pkvm_sme_dvmsync_fw_call(void)
> +{
> + if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714)) {
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_smc(ARM_SMCCC_CPU_WORKAROUND_4193714, &res);
With hyp tracing in kvmarm/next, this should be hyp_smccc_1_1_smc().
> + }
> +}
> +
> static void guest_lock_component(struct pkvm_hyp_vm *vm)
> {
> hyp_spin_lock(&vm->lock);
> @@ -553,6 +564,12 @@ int host_stage2_set_owner_locked(phys_addr_t addr, u64 size, u8 owner_id)
> if (ret)
> return ret;
>
> + /*
> + * After stage2 maintenance has happened, but before the page owner has
> + * changed.
> + */
> + pkvm_sme_dvmsync_fw_call();
> +
> /* Don't forget to update the vmemmap tracking for the host */
> if (owner_id == PKVM_ID_HOST)
> __host_update_page_state(addr, size, PKVM_PAGE_OWNED);
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 50b47eba7d01..e7195750d21b 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -105,6 +105,12 @@
> ARM_SMCCC_SMC_32, \
> 0, 0x3fff)
>
> +/* C1-Pro erratum 4193714: SME DVMSync early acknowledgement */
> +#define ARM_SMCCC_CPU_WORKAROUND_4193714 \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_32, \
> + ARM_SMCCC_OWNER_CPU, 0x10)
> +
> #define ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID \
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> ARM_SMCCC_SMC_32, \
>
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: ti: k3-am62-lp-sk: Add system-power-controller
From: Akashdeep Kaur @ 2026-03-24 10:14 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
In-Reply-To: <20260324101419.95616-1-a-kaur@ti.com>
On AM62-LP-SK, the TPS65219 PMIC is the system power controller
responsible for handling system poweroff. Add the "system-power-controller"
property to the PMIC node to explicitly designate it as such.
Among all in-tree device trees using the TPS65219 PMIC (verified via
compatible string), AM62-LP-SK was the only one missing this property.
This patch corrects that omission.
This property will be used by the PMIC driver to conditionally register
the poweroff handler, ensuring only the designated power controller
registers for system poweroff operations.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts b/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
index 3e2d8f669535..786a7d695b33 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62-lp-sk.dts
@@ -206,6 +206,7 @@ tps65219: pmic@30 {
interrupt-parent = <&gic500>;
interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ system-power-controller;
regulators {
buck1_reg: buck1 {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Akashdeep Kaur @ 2026-03-24 10:14 UTC (permalink / raw)
To: lee, praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy
Cc: vishalm, sebin.francis, d-gole, k-willis, a-kaur
In-Reply-To: <20260324101419.95616-1-a-kaur@ti.com>
Currently, the TPS65219 driver unconditionally registers a poweroff
handler. This causes issues on systems where a different component
(such as TF-A firmware) should handle system poweroff instead.
Make the poweroff handler registration conditional based on the
"system-power-controller" device tree property. This follows the
standard kernel pattern where only the designated power controller
registers for system poweroff operations.
On systems where the property is absent, the PMIC will not register
a poweroff handler, allowing other poweroff mechanisms to function.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/mfd/tps65219.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
index 7275dcdb7c44..6fa202339a0c 100644
--- a/drivers/mfd/tps65219.c
+++ b/drivers/mfd/tps65219.c
@@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
return ret;
}
- ret = devm_register_power_off_handler(tps->dev,
- tps65219_power_off_handler,
- tps);
- if (ret) {
- dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
- return ret;
+ if (of_device_is_system_power_controller(tps->dev->of_node)) {
+ ret = devm_register_power_off_handler(tps->dev,
+ tps65219_power_off_handler,
+ tps);
+ if (ret)
+ return dev_err_probe(tps->dev, ret,
+ "failed to register power-off handler\n");
}
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
From: Marc Zyngier @ 2026-03-24 10:17 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, Marc Zyngier
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu
In-Reply-To: <20260323174713.3183111-1-maz@kernel.org>
On Mon, 23 Mar 2026 17:47:13 +0000, Marc Zyngier wrote:
> Although we are OK with rewriting idregs at finalize time, resetting
> the guest's cpuif (GICv3) or redistributor (GICv3) addresses once
> we start running the guest is a pretty bad idea.
>
> Move back this initialisation to vgic creation time.
>
>
> [...]
Applied to next, thanks!
[1/1] KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time
commit: bb90920c5ae1217449409dc0b5256c6ed4ccab27
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
From: Marc Zyngier @ 2026-03-24 10:17 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, Marc Zyngier
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Mark Brown
In-Reply-To: <20260323174642.3183075-1-maz@kernel.org>
On Mon, 23 Mar 2026 17:46:42 +0000, Marc Zyngier wrote:
> set_id_regs creates a GIC3 guest when possible, and then proceeds
> to write the ID registers as if they were not affected by the presence
> of a GIC. As it turns out, ID_AA64PFR1_EL1 is the proof of the
> contrary.
>
> KVM now makes a point in exposing the GIC support to the guest,
> no matter what userspace says (userspace such as QEMU is known to
> write silly things at times).
>
> [...]
Applied to next, thanks!
[1/1] KVM: arm64: set_id_regs: Allow GICv3 support to be set at runtime
commit: 2b821a6205b8b7fa7f0486507a63a46a06562a2d
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Akashdeep Kaur @ 2026-03-24 10:18 UTC (permalink / raw)
To: Lee Jones
Cc: Bajjuri, Praneeth, Menon, Nishanth, Davis, Andrew,
Raghavendra, Vignesh, kristo@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, aaro.koskinen@iki.fi,
andreas@kemnade.info, khilman@baylibre.com, rogerq@kernel.org,
tony@atomide.com, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Ramamoorthy, Shree, Mahaveer, Vishal,
Francis, Sebin, Gole, Dhruva, Willis, Kendall
In-Reply-To: <20260319112405.GJ554736@google.com>
On 19/03/26 16:54, Lee Jones wrote:
> On Tue, 10 Mar 2026, Akashdeep Kaur wrote:
>
>> Currently, the TPS65219 driver unconditionally registers a poweroff
>> handler. This causes issues on systems where a different component
>> (such as TF-A firmware) should handle system poweroff instead.
>>
>> Make the poweroff handler registration conditional based on the
>> "system-power-controller" device tree property. This follows the
>> standard kernel pattern where only the designated power controller
>> registers for system poweroff operations.
>>
>> On systems where the property is absent, the PMIC will not register
>> a poweroff handler, allowing other poweroff mechanisms to function.
>>
>> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
>> ---
>> drivers/mfd/tps65219.c | 18 ++++++++++++------
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
>> index 7275dcdb7c44..beb816707d8f 100644
>> --- a/drivers/mfd/tps65219.c
>> +++ b/drivers/mfd/tps65219.c
>> @@ -541,13 +541,19 @@ static int tps65219_probe(struct i2c_client *client)
...
>> + /*
>> + * Only register PMIC power-off handler if system-power-controller
>> + * property is present.
>> + */
>> + if (of_device_is_system_power_controller(tps->dev->of_node)) {
>
> The function name `of_device_is_system_power_controller()` is quite
> self-descriptive. Is this comment really necessary? The code seems clear
> enough without it.
Hi Lee, yes, i agree, Removed the comment.
Thanks,
Akashdeep Kaur
>
>> + ret = devm_register_power_off_handler(tps->dev,
>> + tps65219_power_off_handler,
>> + tps);
>> + if (ret)
>> + return dev_err_probe(tps->dev, ret,
>> + "failed to register power-off handler\n");
>> }
>> +
>> return 0;
>> }
>>
>> --
>> 2.34.1
>>
>
^ permalink raw reply
* Re: [PATCH v2 6/9] soc: imx8m: don't access of_root directly
From: Alexander Stein @ 2026-03-24 10:24 UTC (permalink / raw)
To: Rob Herring, Saravana Kannan, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Christophe Leroy (CS GROUP),
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Frank Li, linux-arm-kernel
Cc: devicetree, linux-kernel, linuxppc-dev, linux-arm-kernel, imx,
linux-renesas-soc, linux-sunxi, driver-core, Bartosz Golaszewski,
Bartosz Golaszewski
In-Reply-To: <20260223-soc-of-root-v2-6-b45da45903c8@oss.qualcomm.com>
Hi,
Am Montag, 23. Februar 2026, 14:37:21 CET schrieb Bartosz Golaszewski:
> Don't access of_root directly as it reduces the build test coverage for
> this driver with COMPILE_TEST=y and OF=n. Use existing helper functions
> to retrieve the relevant information.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
today I noticed the following warning running next-20260323:
> caam 30900000.crypto: No clock data provided for i.MX SoC
This happens when there is no matching against the soc_id.
Checking the source it turns out this patch is the cause that the SoC info
does not provide soc_id anymore.
next-20260323:
> $ grep . /sys/devices/soc0/*
> /sys/devices/soc0/family:Freescale i.MX
> /sys/devices/soc0/machine:TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MP-RAS314
> grep: /sys/devices/soc0/power: Is a directory
> /sys/devices/soc0/revision:unknown
> /sys/devices/soc0/serial_number:0000000000000000
> grep: /sys/devices/soc0/subsystem: Is a directory
reverting this patch (2524b293a59e586afd06358d0b191ab57208a920):
> $ grep . /sys/devices/soc0/*
> /sys/devices/soc0/family:Freescale i.MX
> /sys/devices/soc0/machine:TQ-Systems i.MX8MPlus TQMa8MPxL on MBa8MP-RAS314
> grep: /sys/devices/soc0/power: Is a directory
> /sys/devices/soc0/revision:1.1
> /sys/devices/soc0/serial_number:469677A693A4B8CE131D180033E44903
> /sys/devices/soc0/soc_id:i.MX8MP
> grep: /sys/devices/soc0/subsystem: Is a directory
soc_id is restored. Now that I write these lines I noticed that
serial_number also contained empty value which is restored with the revert.
Best regards,
Alexander
> ---
> drivers/soc/imx/soc-imx8m.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
> index 8e2322999f0996d2723768469c6893b0ea22eb9d..77763a107edbd11302017e3f61ecb4369fda1ab0 100644
> --- a/drivers/soc/imx/soc-imx8m.c
> +++ b/drivers/soc/imx/soc-imx8m.c
> @@ -226,7 +226,6 @@ static int imx8m_soc_probe(struct platform_device *pdev)
> const struct imx8_soc_data *data;
> struct imx8_soc_drvdata *drvdata;
> struct device *dev = &pdev->dev;
> - const struct of_device_id *id;
> struct soc_device *soc_dev;
> u32 soc_rev = 0;
> u64 soc_uid[2] = {0, 0};
> @@ -244,15 +243,11 @@ static int imx8m_soc_probe(struct platform_device *pdev)
>
> soc_dev_attr->family = "Freescale i.MX";
>
> - ret = of_property_read_string(of_root, "model", &soc_dev_attr->machine);
> + ret = soc_attr_read_machine(soc_dev_attr);
> if (ret)
> return ret;
>
> - id = of_match_node(imx8_soc_match, of_root);
> - if (!id)
> - return -ENODEV;
> -
> - data = id->data;
> + data = device_get_match_data(dev);
> if (data) {
> soc_dev_attr->soc_id = data->name;
> ret = imx8m_soc_prepare(pdev, data->ocotp_compatible);
> @@ -326,7 +321,7 @@ static int __init imx8_soc_init(void)
> int ret;
>
> /* No match means this is non-i.MX8M hardware, do nothing. */
> - if (!of_match_node(imx8_soc_match, of_root))
> + if (!of_machine_device_match(imx8_soc_match))
> return 0;
>
> ret = platform_driver_register(&imx8m_soc_driver);
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH 1/4] exec: inherit HWCAPs from the parent process
From: Will Deacon @ 2026-03-24 10:28 UTC (permalink / raw)
To: Mark Rutland
Cc: Andrei Vagin, Kees Cook, Andrew Morton, Marek Szyprowski,
Cyrill Gorcunov, Mike Rapoport, Alexander Mikhalitsyn,
linux-kernel, linux-fsdevel, linux-mm, criu, Catalin Marinas,
linux-arm-kernel, Chen Ridong, Christian Brauner,
David Hildenbrand, Eric Biederman, Lorenzo Stoakes, Michal Koutny,
Alexander Mikhalitsyn
In-Reply-To: <acGEonF9I6sPA42B@J2N7QTR9R3.cambridge.arm.com>
On Mon, Mar 23, 2026 at 06:21:22PM +0000, Mark Rutland wrote:
> On Mon, Mar 23, 2026 at 05:53:37PM +0000, Andrei Vagin wrote:
> > Introduces a mechanism to inherit hardware capabilities (AT_HWCAP,
> > AT_HWCAP2, etc.) from a parent process when they have been modified via
> > prctl.
> >
> > To support C/R operations (snapshots, live migration) in heterogeneous
> > clusters, we must ensure that processes utilize CPU features available
> > on all potential target nodes. To solve this, we need to advertise a
> > common feature set across the cluster.
> >
> > This patch adds a new mm flag MMF_USER_HWCAP, which is set when the
> > auxiliary vector is modified via prctl(PR_SET_MM, PR_SET_MM_AUXV). When
> > execve() is called, if the current process has MMF_USER_HWCAP set, the
> > HWCAP values are extracted from the current auxiliary vector and stored
> > in the linux_binprm structure. These values are then used to populate
> > the auxiliary vector of the new process, effectively inheriting the
> > hardware capabilities.
> >
> > The inherited HWCAPs are masked with the hardware capabilities supported
> > by the current kernel to ensure that we don't report more features than
> > actually supported. This is important to avoid unexpected behavior,
> > especially for processes with additional privileges.
>
> At a high level, I don't think that's going to be sufficient:
>
> * On an architecture with other userspace accessible feature
> identification mechanism registers (e.g. ID registers), userspace
> might read those. So you might need to hide stuff there too, and
> that's going to require architecture-specific interfaces to manage.
>
> It's possible that some code checks HWCAPs and others check ID
> registers, and mismatch between the two could be problematic.
>
> * If the HWCAPs can be inherited by a more privileged task, then a
> malicious user could use this to hide security features (e.g. shadow
> stack or pointer authentication on arm64), and make it easier to
> attack that task. While not a direct attack, it would undermine those
> features.
Yeah, this looks like a non-starter to me on arm64. Even if it was
extended to apply the same treatment to the idregs, many of the hwcap
features can't actually be disabled by the kernel and so you still run
the risk of a task that probes for the presence of a feature using
something like a SIGILL handler or, perhaps more likely, assumes that
the presence of one hwcap implies the presence of another. And then
there are the applications that just base everything off the MIDR...
There's also kvm, which provides a roundabout way to query some features
of the underlying hardware.
You're probably better off using/extending the idreg overrides we have
in arch/arm64/kernel/pi/idreg-override.c so that you can make your
cluster of heterogeneous machines look alike.
On the other hand, if munging the hwcaps happens to be sufficient for
this particular use-case, can't it be handled entirely in userspace (e.g.
by hacking libc?)
Will
^ permalink raw reply
* Re: [PATCH 0/6] media: synopsys: Add imx93 support
From: Sakari Ailus @ 2026-03-24 10:35 UTC (permalink / raw)
To: Michael Riesch
Cc: Sakari Ailus, Frank Li, Mauro Carvalho Chehab, Philipp Zabel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree,
linux-arm-kernel, linux-rockchip, Guoniu Zhou, imx
In-Reply-To: <08e6b649-61ac-4059-a914-c537b5c4da7e@collabora.com>
Hi Michael,
On Tue, Mar 24, 2026 at 10:46:49AM +0100, Michael Riesch wrote:
> Hi all,
>
> On 3/24/26 09:18, Sakari Ailus wrote:
> > On Mon, Mar 23, 2026 at 03:10:44PM -0400, Frank Li wrote:
> >> On Tue, Feb 10, 2026 at 12:11:07PM -0500, Frank Li wrote:
> >>> This 3rd time try to support DW CSI2RX support for imx93.
> >>>
> >>
> >> Laurent Pinchart and Sakari Ailus:
> >>
> >> I am not who will take care this patch?
> >> original drivers/media/platform/synopsys/dw-mipi-csi2rx.c picked
> >> by Sakari Ailus
> >
> > Michael seems to have questions on the last patch, too.
>
> I.. don't.. think so. After digging a bit in my memory and lore, I found
> a v3 of that series with my Reviewed-by [0]
>
> [0]
> https://lore.kernel.org/all/20260216-imx93-dw-csi2-v3-0-aabafee10923@nxp.com/
Message-Id <9e14d605-9419-441e-a554-432d435191b3@collabora.com>.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v2] tpm: i2c: atmel: fix block comment formatting
From: Jarkko Sakkinen @ 2026-03-24 10:37 UTC (permalink / raw)
To: Ethan Luna
Cc: peterhuewe, jgg, nicolas.ferre, claudiu.beznea, linux-integrity,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260323134200.7766-1-trunixcodes@zohomail.com>
On Mon, Mar 23, 2026 at 06:40:49AM -0700, Ethan Luna wrote:
> Multiple block comments in tpm_i2c_atmel.c placed the closing '*/' on the
> same line as the comment text. This violates the kernel's preferred
> comment style, which requires the closing delimiter to appear on its
> line.
>
> Fix the formatting to improve readability and resolve checkpatch
> warnings.
>
> Signed-off-by: Ethan Luna <trunixcodes@zohomail.com>
> ---
>
> V1 -> V2: Fixed block comment formatting consistently across all multi-line comments
>
> v1: https://lore.kernel.org/all/20260322193112.27010-1-trunixcodes@zohomail.com/
>
> drivers/char/tpm/tpm_i2c_atmel.c | 34 +++++++++++++++++++++-----------
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
> index 4f229656a8e2..c3cdc0d6e61c 100644
> --- a/drivers/char/tpm/tpm_i2c_atmel.c
> +++ b/drivers/char/tpm/tpm_i2c_atmel.c
> @@ -31,9 +31,11 @@
>
> struct priv_data {
> size_t len;
> - /* This is the amount we read on the first try. 25 was chosen to fit a
> + /*
> + * This is the amount we read on the first try. 25 was chosen to fit a
> * fair number of read responses in the buffer so a 2nd retry can be
> - * avoided in small message cases. */
> + * avoided in small message cases.
> + */
> u8 buffer[sizeof(struct tpm_header) + 25];
> };
>
> @@ -58,7 +60,9 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
> if (status < 0)
> return status;
>
> - /* The upper layer does not support incomplete sends. */
> + /*
> + * The upper layer does not support incomplete sends.
> + */
> if (status != len)
> return -E2BIG;
>
> @@ -76,9 +80,11 @@ static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> if (priv->len == 0)
> return -EIO;
>
> - /* Get the message size from the message header, if we didn't get the
> + /*
> + * Get the message size from the message header, if we didn't get the
> * whole message in read_status then we need to re-read the
> - * message. */
> + * message.
> + */
> expected_len = be32_to_cpu(hdr->length);
> if (expected_len > count)
> return -ENOMEM;
> @@ -111,15 +117,19 @@ static u8 i2c_atmel_read_status(struct tpm_chip *chip)
> struct i2c_client *client = to_i2c_client(chip->dev.parent);
> int rc;
>
> - /* The TPM fails the I2C read until it is ready, so we do the entire
> + /*
> + * The TPM fails the I2C read until it is ready, so we do the entire
> * transfer here and buffer it locally. This way the common code can
> - * properly handle the timeouts. */
> + * properly handle the timeouts.
> + */
> priv->len = 0;
> memset(priv->buffer, 0, sizeof(priv->buffer));
>
>
> - /* Once the TPM has completed the command the command remains readable
> - * until another command is issued. */
> + /*
> + * Once the TPM has completed the command the command remains readable
> + * until another command is issued.
> + */
> rc = i2c_master_recv(client, priv->buffer, sizeof(priv->buffer));
> dev_dbg(&chip->dev,
> "%s: sts=%d", __func__, rc);
> @@ -172,9 +182,11 @@ static int i2c_atmel_probe(struct i2c_client *client)
>
> dev_set_drvdata(&chip->dev, priv);
>
> - /* There is no known way to probe for this device, and all version
> + /*
> + * There is no known way to probe for this device, and all version
> * information seems to be read via TPM commands. Thus we rely on the
> - * TPM startup process in the common code to detect the device. */
> + * TPM startup process in the common code to detect the device.
> + */
>
> return tpm_chip_register(chip);
> }
> --
> 2.53.0
>
Almost there but when I applied it I spotted some trailing whitespace
errors:
❯ scripts/checkpatch.pl --strict -g HEAD
ERROR: trailing whitespace
#30: FILE: drivers/char/tpm/tpm_i2c_atmel.c:34:
+^I/* $
ERROR: trailing whitespace
#55: FILE: drivers/char/tpm/tpm_i2c_atmel.c:83:
+^I/* $
ERROR: trailing whitespace
#69: FILE: drivers/char/tpm/tpm_i2c_atmel.c:120:
+^I/* $
ERROR: trailing whitespace
#81: FILE: drivers/char/tpm/tpm_i2c_atmel.c:129:
+^I/* $
ERROR: trailing whitespace
#93: FILE: drivers/char/tpm/tpm_i2c_atmel.c:185:
+^I/* $
total: 5 errors, 0 warnings, 0 checks, 72 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
Commit fe31e9522c2c ("tpm: i2c: atmel: fix block comment formatting") has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH 01/14] KVM: arm64: Donate MMIO to the hypervisor
From: Vincent Donnefort @ 2026-03-24 10:39 UTC (permalink / raw)
To: Sebastian Ene
Cc: alexandru.elisei, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, catalin.marinas, dbrazdil, joey.gouly, kees,
mark.rutland, maz, oupton, perlarsen, qperret, rananta, smostafa,
suzuki.poulose, tabba, tglx, bgrzesik, will, yuzenghui
In-Reply-To: <20260310124933.830025-2-sebastianene@google.com>
On Tue, Mar 10, 2026 at 12:49:20PM +0000, Sebastian Ene wrote:
> From: Mostafa Saleh <smostafa@google.com>
>
> Add a function to donate MMIO to the hypervisor so IOMMU hypervisor
> drivers can use that to protect the MMIO of IOMMU.
> The initial attempt to implement this was to have a new flag to
> "___pkvm_host_donate_hyp" to accept MMIO. However that had many problems,
> it was quite intrusive for host/hyp to check/set page state to make it
> aware of MMIO and to encode the state in the page table in that case.
> Which is called in paths that can be sensitive to performance (FFA, VMs..)
>
> As donating MMIO is very rare, and we don’t need to encode the full
> state, it’s reasonable to have a separate function to do this.
> It will init the host s2 page table with an invalid leaf with the owner ID
> to prevent the host from mapping the page on faults.
I am not sure I agree here:
* Differentiating between MMIO and Memory is just a fast binary search into the
memory regions.
* host_donate_hyp isn't a fast path even for memory regions anyway.
* Having common functions for changing ownership is more and more helpful (see the
SME dvmsync workaround).
* There's nothing preventing from having a range here which is safely handled
already by host_donate_hyp()
>
> Also, prevent kvm_pgtable_stage2_unmap() from removing owner ID from
> stage-2 PTEs, as this can be triggered from recycle logic under memory
> pressure. There is no code relying on this, as all ownership changes is
> done via kvm_pgtable_stage2_set_owner()
>
> For error path in IOMMU drivers, add a function to donate MMIO back
> from hyp to host.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 90 +++++++++++++++++++
> arch/arm64/kvm/hyp/pgtable.c | 9 +-
> 3 files changed, 94 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> index 5f9d56754e39..8b617e6fc0e0 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
> @@ -31,6 +31,8 @@ enum pkvm_component_id {
> };
>
> extern unsigned long hyp_nr_cpus;
> +int __pkvm_host_donate_hyp_mmio(u64 pfn);
> +int __pkvm_hyp_donate_host_mmio(u64 pfn);
>
> int __pkvm_prot_finalize(void);
> int __pkvm_host_share_hyp(u64 pfn);
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 38f66a56a766..0808367c52e5 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -784,6 +784,96 @@ int __pkvm_host_unshare_hyp(u64 pfn)
> return ret;
> }
>
> +int __pkvm_host_donate_hyp_mmio(u64 pfn)
> +{
> + u64 phys = hyp_pfn_to_phys(pfn);
> + void *virt = __hyp_va(phys);
> + int ret;
> + kvm_pte_t pte;
> +
> + if (addr_is_memory(phys))
> + return -EINVAL;
> +
> + host_lock_component();
> + hyp_lock_component();
> +
> + ret = kvm_pgtable_get_leaf(&host_mmu.pgt, phys, &pte, NULL);
> + if (ret)
> + goto unlock;
> +
> + if (pte && !kvm_pte_valid(pte)) {
> + ret = -EPERM;
> + goto unlock;
> + }
> +
> + ret = kvm_pgtable_get_leaf(&pkvm_pgtable, (u64)virt, &pte, NULL);
> + if (ret)
> + goto unlock;
> + if (pte) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> +
gg> + ret = pkvm_create_mappings_locked(virt, virt + PAGE_SIZE, PAGE_HYP_DEVICE);
> gg+ if (ret)
> + goto unlock;
> + /*
> + * We set HYP as the owner of the MMIO pages in the host stage-2, for:
> + * - host aborts: host_stage2_adjust_range() would fail for invalid non zero PTEs.
> + * - recycle under memory pressure: host_stage2_unmap_dev_all() would call
> + * kvm_pgtable_stage2_unmap() which will not clear non zero invalid ptes (counted).
> + * - other MMIO donation: Would fail as we check that the PTE is valid or empty.
> + */
> + WARN_ON(host_stage2_try(kvm_pgtable_stage2_set_owner, &host_mmu.pgt, phys,
> + PAGE_SIZE, &host_s2_pool, PKVM_ID_HYP));
> +unlock:
> + hyp_unlock_component();
> + host_unlock_component();
> +
> + return ret;
> +}
> +
> +int __pkvm_hyp_donate_host_mmio(u64 pfn)
> +{
> + u64 phys = hyp_pfn_to_phys(pfn);
> + u64 virt = (u64)__hyp_va(phys);
> + size_t size = PAGE_SIZE;
> + int ret;
> + kvm_pte_t pte;
> +
> + if (addr_is_memory(phys))
> + return -EINVAL;
> +
> + host_lock_component();
> + hyp_lock_component();
> +
> + ret = kvm_pgtable_get_leaf(&pkvm_pgtable, (u64)virt, &pte, NULL);
> + if (ret)
> + goto unlock;
> + if (!kvm_pte_valid(pte)) {
> + ret = -ENOENT;
> + goto unlock;
> + }
> +
> + ret = kvm_pgtable_get_leaf(&host_mmu.pgt, phys, &pte, NULL);
> + if (ret)
> + goto unlock;
> +
> + if (FIELD_GET(KVM_INVALID_PTE_OWNER_MASK, pte) != PKVM_ID_HYP) {
> + ret = -EPERM;
> + goto unlock;
> + }
> +
> + WARN_ON(kvm_pgtable_hyp_unmap(&pkvm_pgtable, virt, size) != size);
> + WARN_ON(host_stage2_try(kvm_pgtable_stage2_set_owner, &host_mmu.pgt, phys,
> + PAGE_SIZE, &host_s2_pool, PKVM_ID_HOST));
> +unlock:
> + hyp_unlock_component();
> + host_unlock_component();
> +
> + return ret;
> +}
> +
> int __pkvm_host_donate_hyp(u64 pfn, u64 nr_pages)
> {
> u64 phys = hyp_pfn_to_phys(pfn);
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 9b480f947da2..d954058e63ff 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -1152,13 +1152,8 @@ static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
> kvm_pte_t *childp = NULL;
> bool need_flush = false;
>
> - if (!kvm_pte_valid(ctx->old)) {
> - if (stage2_pte_is_counted(ctx->old)) {
> - kvm_clear_pte(ctx->ptep);
> - mm_ops->put_page(ctx->ptep);
> - }
> - return 0;
> - }
> + if (!kvm_pte_valid(ctx->old))
> + return stage2_pte_is_counted(ctx->old) ? -EPERM : 0;
>
> if (kvm_pte_table(ctx->old, ctx->level)) {
> childp = kvm_pte_follow(ctx->old, mm_ops);
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
* Re: [PATCH v4 01/21] mm: various small mmap_prepare cleanups
From: Vlastimil Babka (SUSE) @ 2026-03-24 10:46 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <99f408e4694f44ab12bdc55fe0bd9685d3bd1117.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Rather than passing arbitrary fields, pass a vm_area_desc pointer to mmap
> prepare functions to mmap prepare, and an action and vma pointer to mmap
> complete in order to put all the action-specific logic in the function
> actually doing the work.
>
> Additionally, allow mmap prepare functions to return an error so we can
> error out as soon as possible if there is something logically incorrect in
> the input.
>
> Update remap_pfn_range_prepare() to properly check the input range for the
> CoW case.
>
> Also remove io_remap_pfn_range_complete(), as we can simply set up the
> fields correctly in io_remap_pfn_range_prepare() and use
> remap_pfn_range_complete() for this.
>
> While we're here, make remap_pfn_range_prepare_vma() a little neater, and
> pass mmap_action directly to call_action_complete().
>
> Then, update compat_vma_mmap() to perform its logic directly, as
> __compat_vma_map() is not used by anything so we don't need to export it.
>
> Also update compat_vma_mmap() to use vfs_mmap_prepare() rather than
> calling the mmap_prepare op directly.
>
> Finally, update the VMA userland tests to reflect the changes.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH 02/14] KVM: arm64: Track host-unmapped MMIO regions in a static array
From: Vincent Donnefort @ 2026-03-24 10:46 UTC (permalink / raw)
To: Sebastian Ene
Cc: alexandru.elisei, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, catalin.marinas, dbrazdil, joey.gouly, kees,
mark.rutland, maz, oupton, perlarsen, qperret, rananta, smostafa,
suzuki.poulose, tabba, tglx, bgrzesik, will, yuzenghui
In-Reply-To: <20260310124933.830025-3-sebastianene@google.com>
On Tue, Mar 10, 2026 at 12:49:21PM +0000, Sebastian Ene wrote:
> Introduce a registry to track protected MMIO regions that are unmapped
> from the host stage-2 page tables. These regions are stored in a
> fixed-size array and their ownership is donated to the hypervisor during
> initialization to ensure host-exclusion and persistent tracking.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/include/asm/kvm_pkvm.h | 10 ++++++++++
> arch/arm64/kvm/hyp/nvhe/mem_protect.c | 3 +++
> arch/arm64/kvm/hyp/nvhe/setup.c | 25 +++++++++++++++++++++++++
> 3 files changed, 38 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h
> index 757076ad4ec9..48ec7d519399 100644
> --- a/arch/arm64/include/asm/kvm_pkvm.h
> +++ b/arch/arm64/include/asm/kvm_pkvm.h
> @@ -17,6 +17,16 @@
>
> #define HYP_MEMBLOCK_REGIONS 128
>
> +#define PKVM_PROTECTED_REGS_NUM 8
> +
> +struct pkvm_protected_reg {
> + u64 start_pfn;
> + size_t num_pages;
nit: "u64 pfn, u64 nr_pages" to align with everywhere else.
> +};
> +
> +extern struct pkvm_protected_reg kvm_nvhe_sym(pkvm_protected_regs)[];
> +extern unsigned int kvm_nvhe_sym(num_protected_reg);
> +
> int pkvm_init_host_vm(struct kvm *kvm);
> int pkvm_create_hyp_vm(struct kvm *kvm);
> bool pkvm_hyp_vm_is_created(struct kvm *kvm);
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 0808367c52e5..7c125836b533 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -23,6 +23,9 @@
>
> struct host_mmu host_mmu;
>
> +struct pkvm_protected_reg pkvm_protected_regs[PKVM_PROTECTED_REGS_NUM];
> +unsigned int num_protected_reg;
> +
> static struct hyp_pool host_s2_pool;
>
> static DEFINE_PER_CPU(struct pkvm_hyp_vm *, __current_vm);
> diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> index 90bd014e952f..ad5b96085e1b 100644
> --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> @@ -284,6 +284,27 @@ static int fix_hyp_pgtable_refcnt(void)
> &walker);
> }
>
> +static int unmap_protected_regions(void)
> +{
> + struct pkvm_protected_reg *reg;
> + int i, ret, j = 0;
> +
> + for (i = 0; i < num_protected_reg; i++) {
> + reg = &pkvm_protected_regs[i];
> + for (j = 0; j < reg->num_pages; j++) {
> + ret = __pkvm_host_donate_hyp_mmio(reg->start_pfn + j);
If this is to make this static at boot, we don't even need __pkvm_host_donate_hyp_mmio()
We can just map the region early enough in the hypervisor pkvm_create_mappings()
in recreate_hyp_mappings() and then let fix_host_ownership() do the host
stage2 unmapping.
> + if (ret)
> + goto err_setup;
> + }
> + }
> +
> + return 0;
> +err_setup:
> + for (j = j - 1; j >= 0; j--)
> + __pkvm_hyp_donate_host_mmio(reg->start_pfn + j);
> + return ret;
> +}
> +
> void __noreturn __pkvm_init_finalise(void)
> {
> struct kvm_cpu_context *host_ctxt = host_data_ptr(host_ctxt);
> @@ -324,6 +345,10 @@ void __noreturn __pkvm_init_finalise(void)
> if (ret)
> goto out;
>
> + ret = unmap_protected_regions();
> + if (ret)
> + goto out;
> +
> ret = hyp_ffa_init(ffa_proxy_pages);
> if (ret)
> goto out;
> --
> 2.53.0.473.g4a7958ca14-goog
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox