<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/riscv, branch master</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Merge tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2026-08-02T19:12:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-08-02T19:12:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f5a7e2ae5f0a9a5caf59501457938eeb249a7dc8'/>
<id>f5a7e2ae5f0a9a5caf59501457938eeb249a7dc8</id>
<content type='text'>
Pull RISC-V fixes from Paul Walmsley:

 - Fix swiotlb initialization on systems where DRAM is located above
   4GiB (such as the Tenstorrent Blackhole cards)

 - Fix an out-of-bounds access in the memory hot-remove code that can
   occur on Sv39 and Sv48 systems

 - Avoid oopsing during boot if the SBI component of the unaligned
   access performance checking code loses a race against __init function
   freeing

 - Avoid attempting to install the debug-enabled vDSO when it shouldn't
   be built due to !CONFIG_MMU

 - Avoid some sparse warnings by adding missing __iomem notations in
   get_cycles{,_hi}()

 - Drop an unnecessary runtime warning in the SiFive errata handler

* tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: vdso: Only try to install vDSO when present
  riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove
  riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
  riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
  riscv/sifive: remove warning in errata
  riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull RISC-V fixes from Paul Walmsley:

 - Fix swiotlb initialization on systems where DRAM is located above
   4GiB (such as the Tenstorrent Blackhole cards)

 - Fix an out-of-bounds access in the memory hot-remove code that can
   occur on Sv39 and Sv48 systems

 - Avoid oopsing during boot if the SBI component of the unaligned
   access performance checking code loses a race against __init function
   freeing

 - Avoid attempting to install the debug-enabled vDSO when it shouldn't
   be built due to !CONFIG_MMU

 - Avoid some sparse warnings by adding missing __iomem notations in
   get_cycles{,_hi}()

 - Drop an unnecessary runtime warning in the SiFive errata handler

* tag 'riscv-for-linus-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: vdso: Only try to install vDSO when present
  riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove
  riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
  riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
  riscv/sifive: remove warning in errata
  riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: vdso: Only try to install vDSO when present</title>
<updated>2026-07-29T23:55:17+00:00</updated>
<author>
<name>Thomas Weißschuh</name>
<email>thomas.weissschuh@linutronix.de</email>
</author>
<published>2026-07-09T06:49:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c052927905710de1ab7364bf1925efbd12517ea3'/>
<id>c052927905710de1ab7364bf1925efbd12517ea3</id>
<content type='text'>
vdso.so.dbg is only built with CONFIG_MMU.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202607090258.iSAUYlO1-lkp@intel.com/
Fixes: f157d411a9eb ("riscv: add missing vdso_install target")
Fixes: 3edf39916977 ("vDSO, kbuild: Provide vDSO debug variants at runtime")
Signed-off-by: Thomas Weißschuh &lt;thomas.weissschuh@linutronix.de&gt;
Link: https://patch.msgid.link/20260709-riscv-install-vdso-v1-1-0ba4345419ca@linutronix.de
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
vdso.so.dbg is only built with CONFIG_MMU.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202607090258.iSAUYlO1-lkp@intel.com/
Fixes: f157d411a9eb ("riscv: add missing vdso_install target")
Fixes: 3edf39916977 ("vDSO, kbuild: Provide vDSO debug variants at runtime")
Signed-off-by: Thomas Weißschuh &lt;thomas.weissschuh@linutronix.de&gt;
Link: https://patch.msgid.link/20260709-riscv-install-vdso-v1-1-0ba4345419ca@linutronix.de
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove</title>
<updated>2026-07-29T23:35:05+00:00</updated>
<author>
<name>Karl Mehltretter</name>
<email>kmehltretter@gmail.com</email>
</author>
<published>2026-07-29T01:21:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a0188cc133696627857d16054e43f9ebc7efc821'/>
<id>a0188cc133696627857d16054e43f9ebc7efc821</id>
<content type='text'>
remove_pud_mapping() and remove_p4d_mapping() obtain a child table base
with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for
addr.

RISC-V folds page-table levels at runtime. When a level is folded, its
offset helper returns the parent entry itself, but the index can still be
nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39
folds both P4D and PUD, so memory hot-remove can descend into unrelated
memory and pass an invalid page to __free_pages(). This can trigger:

  kernel BUG at include/linux/mm.h:1810!
  VM_BUG_ON_PAGE(page_ref_count(page) == 0)
  arch_remove_memory+0x1e/0x5c
  try_remove_memory+0x15e/0x200
  remove_memory+0x24/0x3c

Only add the index when the corresponding page-table level is enabled,
matching p4d_offset() and pud_offset().

Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter &lt;kmehltretter@gmail.com&gt;
Link: https://patch.msgid.link/20260729012132.24882-1-kmehltretter@gmail.com
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
remove_pud_mapping() and remove_p4d_mapping() obtain a child table base
with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for
addr.

RISC-V folds page-table levels at runtime. When a level is folded, its
offset helper returns the parent entry itself, but the index can still be
nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39
folds both P4D and PUD, so memory hot-remove can descend into unrelated
memory and pass an invalid page to __free_pages(). This can trigger:

  kernel BUG at include/linux/mm.h:1810!
  VM_BUG_ON_PAGE(page_ref_count(page) == 0)
  arch_remove_memory+0x1e/0x5c
  try_remove_memory+0x15e/0x200
  remove_memory+0x24/0x3c

Only add the index when the corresponding page-table level is enabled,
matching p4d_offset() and pud_offset().

Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter &lt;kmehltretter@gmail.com&gt;
Link: https://patch.msgid.link/20260729012132.24882-1-kmehltretter@gmail.com
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: drop __init from vec_check_unaligned_access_speed_all_cpus</title>
<updated>2026-07-29T19:24:24+00:00</updated>
<author>
<name>Anirudh Srinivasan</name>
<email>asrinivasan@oss.tenstorrent.com</email>
</author>
<published>2026-06-12T16:24:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f51fed61eea0daba2f95f1a6074085e4cd513c7b'/>
<id>f51fed61eea0daba2f95f1a6074085e4cd513c7b</id>
<content type='text'>
This function runs within a kthread and need not necessarily finish
before system finishes boot and free_initmem() unmaps the .init.text
section. This function makes calls to SBI for probing unaligned access
speed, and if this is slow for some reason (say some debug prints were
added to SBI), the kthread can still be running at this point and result
in an instruction page fault when trying to fetch from the freed region.

[   25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8
[   25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000
[   25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3
[   25.661244] Oops [#1]
[   25.662997] Modules linked in:
[   25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY
[   25.674669] Hardware name: Tenstorrent Blackhole (DT)
[   25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.683458]  ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20
[   25.693874]  gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000
[   25.699401]  t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30
[   25.704912]  s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002
[   25.710407]  a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000
[   25.715917]  a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30
[   25.721419]  s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0
[   25.726937]  s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
[   25.732450]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[   25.737944]  s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402
[   25.743481]  t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000
[   25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c
[   25.755060] [&lt;ffffffff80a04ef8&gt;] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.760964] [&lt;ffffffff80047a10&gt;] kthread+0xd8/0xfc
[   25.764660] [&lt;ffffffff80010c48&gt;] ret_from_fork_kernel+0x18/0x1c4
[   25.769220] [&lt;ffffffff80895fe6&gt;] ret_from_fork_kernel_asm+0x16/0x18
[   25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc

Drop __init from its signature so that this doesn't happen.

Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions")
Signed-off-by: Anirudh Srinivasan &lt;asrinivasan@oss.tenstorrent.com&gt;
Assisted-by: Claude:claude-opus-4-6
Link: https://patch.msgid.link/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This function runs within a kthread and need not necessarily finish
before system finishes boot and free_initmem() unmaps the .init.text
section. This function makes calls to SBI for probing unaligned access
speed, and if this is slow for some reason (say some debug prints were
added to SBI), the kthread can still be running at this point and result
in an instruction page fault when trying to fetch from the freed region.

[   25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8
[   25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000
[   25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3
[   25.661244] Oops [#1]
[   25.662997] Modules linked in:
[   25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY
[   25.674669] Hardware name: Tenstorrent Blackhole (DT)
[   25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.683458]  ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20
[   25.693874]  gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000
[   25.699401]  t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30
[   25.704912]  s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002
[   25.710407]  a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000
[   25.715917]  a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30
[   25.721419]  s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0
[   25.726937]  s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
[   25.732450]  s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[   25.737944]  s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402
[   25.743481]  t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000
[   25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c
[   25.755060] [&lt;ffffffff80a04ef8&gt;] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[   25.760964] [&lt;ffffffff80047a10&gt;] kthread+0xd8/0xfc
[   25.764660] [&lt;ffffffff80010c48&gt;] ret_from_fork_kernel+0x18/0x1c4
[   25.769220] [&lt;ffffffff80895fe6&gt;] ret_from_fork_kernel_asm+0x16/0x18
[   25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc

Drop __init from its signature so that this doesn't happen.

Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions")
Signed-off-by: Anirudh Srinivasan &lt;asrinivasan@oss.tenstorrent.com&gt;
Assisted-by: Claude:claude-opus-4-6
Link: https://patch.msgid.link/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB</title>
<updated>2026-07-29T17:43:50+00:00</updated>
<author>
<name>Troy Mitchell</name>
<email>troy.mitchell@linux.dev</email>
</author>
<published>2026-07-27T08:08:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cfca5a48b03fbd33c8cb84cb73ee2e34467f3a33'/>
<id>cfca5a48b03fbd33c8cb84cb73ee2e34467f3a33</id>
<content type='text'>
On RISC-V platforms where the entire physical memory (DRAM) resides
above the 32-bit address space (i.e., above dma32_phys_limit), the
current SWIOTLB initialization logic fails.

This patch addresses two interconnected issues on such platforms:

1. Incorrect 32-bit DMA bounce assumption:
The existing condition `max_pfn &gt; PFN_DOWN(dma32_phys_limit)` assumes
that a 32-bit DMA bounce buffer is required simply because the maximum
PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB,
no memory exists below the limit to satisfy this allocation. Fix
this by adding a check to ensure `memblock_start_of_DRAM()` is actually
below the 32-bit limit before enforcing 32-bit SWIOTLB.

2. kmalloc() bounce buffer allocation failure on non-coherent systems:
For non-coherent DMA, kmalloc() buffers whose sizes are not
cache-line-aligned still require bouncing, even if 32-bit DMA bouncing
is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to
allocating from low memory, which fails completely when DRAM only exists
in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator
is permitted to allocate this bounce buffer from high memory.

With this patch, systems with non-coherent DMA and DRAM entirely above
4GB can successfully map the software IO TLB in high memory and boot
normally.

Tested-by: Anirudh Srinivasan &lt;asrinivasan@oss.tenstorrent.com&gt;
Signed-off-by: Troy Mitchell &lt;troy.mitchell@linux.dev&gt;
Link: https://patch.msgid.link/20260727-fix-riscv-swiotlb-v3-1-59479b23736c@linux.dev
Reviewed-by: Drew Fustini &lt;fustini@kernel.org&gt;
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On RISC-V platforms where the entire physical memory (DRAM) resides
above the 32-bit address space (i.e., above dma32_phys_limit), the
current SWIOTLB initialization logic fails.

This patch addresses two interconnected issues on such platforms:

1. Incorrect 32-bit DMA bounce assumption:
The existing condition `max_pfn &gt; PFN_DOWN(dma32_phys_limit)` assumes
that a 32-bit DMA bounce buffer is required simply because the maximum
PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB,
no memory exists below the limit to satisfy this allocation. Fix
this by adding a check to ensure `memblock_start_of_DRAM()` is actually
below the 32-bit limit before enforcing 32-bit SWIOTLB.

2. kmalloc() bounce buffer allocation failure on non-coherent systems:
For non-coherent DMA, kmalloc() buffers whose sizes are not
cache-line-aligned still require bouncing, even if 32-bit DMA bouncing
is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to
allocating from low memory, which fails completely when DRAM only exists
in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator
is permitted to allocate this bounce buffer from high memory.

With this patch, systems with non-coherent DMA and DRAM entirely above
4GB can successfully map the software IO TLB in high memory and boot
normally.

Tested-by: Anirudh Srinivasan &lt;asrinivasan@oss.tenstorrent.com&gt;
Signed-off-by: Troy Mitchell &lt;troy.mitchell@linux.dev&gt;
Link: https://patch.msgid.link/20260727-fix-riscv-swiotlb-v3-1-59479b23736c@linux.dev
Reviewed-by: Drew Fustini &lt;fustini@kernel.org&gt;
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>riscv/sifive: remove warning in errata</title>
<updated>2026-07-29T17:43:28+00:00</updated>
<author>
<name>Yong-Xuan Wang</name>
<email>yongxuan.wang@sifive.com</email>
</author>
<published>2026-07-29T17:43:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9a22a1542ca03381dcbf000d7a264cbee61e7203'/>
<id>9a22a1542ca03381dcbf000d7a264cbee61e7203</id>
<content type='text'>
The alternative patching of sifive vendor extensions also calls the
sifive_errata_patch_func(), but the patch_id of the vendor extension
(ext + RISCV_VENDOR_EXT_ALTERNATIVES_BASE) is always larger than
ERRATA_SIFIVE_NUMBER. Remove this unnecessary warning.

Signed-off-by: Yong-Xuan Wang &lt;yongxuan.wang@sifive.com&gt;
Link: https://patch.msgid.link/20260503-sifive_errata-v1-1-6f12a81bc267@sifive.com
[pjw@kernel.org: drop unnecessary braces]
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The alternative patching of sifive vendor extensions also calls the
sifive_errata_patch_func(), but the patch_id of the vendor extension
(ext + RISCV_VENDOR_EXT_ALTERNATIVES_BASE) is always larger than
ERRATA_SIFIVE_NUMBER. Remove this unnecessary warning.

Signed-off-by: Yong-Xuan Wang &lt;yongxuan.wang@sifive.com&gt;
Link: https://patch.msgid.link/20260503-sifive_errata-v1-1-6f12a81bc267@sifive.com
[pjw@kernel.org: drop unnecessary braces]
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()</title>
<updated>2026-07-29T17:43:28+00:00</updated>
<author>
<name>Nam Cao</name>
<email>namcao@linutronix.de</email>
</author>
<published>2026-07-29T17:43:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=779e0eb18c774b81a462a6ee89cfbc9eb2d3cee5'/>
<id>779e0eb18c774b81a462a6ee89cfbc9eb2d3cee5</id>
<content type='text'>
__iomem is missing while calling readl_relaxed() in get_cycles() and
get_cycles_hi() and sparse complains.

Add __iomem to silence the sparse warnings.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202607160619.14G8GHp5-lkp@intel.com/
Signed-off-by: Nam Cao &lt;namcao@linutronix.de&gt;
Link: https://patch.msgid.link/20260716053319.2178937-1-namcao@linutronix.de
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__iomem is missing while calling readl_relaxed() in get_cycles() and
get_cycles_hi() and sparse complains.

Add __iomem to silence the sparse warnings.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202607160619.14G8GHp5-lkp@intel.com/
Signed-off-by: Nam Cao &lt;namcao@linutronix.de&gt;
Link: https://patch.msgid.link/20260716053319.2178937-1-namcao@linutronix.de
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv/mm: use physical alignment for vmemmap_start_pfn</title>
<updated>2026-07-29T00:37:32+00:00</updated>
<author>
<name>Jiakai Xu</name>
<email>xujiakai2025@iscas.ac.cn</email>
</author>
<published>2026-07-16T11:53:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=45ebe4540817cb540a59e4dc04014ac5dddc9990'/>
<id>45ebe4540817cb540a59e4dc04014ac5dddc9990</id>
<content type='text'>
RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to
VMEMMAP_ADDR_ALIGN.  That alignment must therefore be expressed in the
physical-address domain.

Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
attempted to account for the maximal folio alignment by feeding
MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN.  However,
MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage,
whereas VMEMMAP_ADDR_ALIGN is used to align a physical address.

The mask-based compound_info encoding requires pfn_to_page(0) to be
naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN.  Commit 9f94db4c7eaa
("mm/sparse: check memmap alignment for compound_info_has_mask()") added a
check for that requirement and exposed the unit mismatch on systems such
as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES *
PAGE_SIZE.

Here is the log:
[    0.000000][    C0] ------------[ cut here ]------------
[    0.000000][    C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0
[    0.000000][    C0] Modules linked in:
[    0.000000][    C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT 
[    0.000000][    C0] Hardware name: riscv-virtio,qemu (DT)
[    0.000000][    C0] epc : sparse_init+0x58a/0x6fe
[    0.000000][    C0]  ra : sparse_init+0x58a/0x6fe
[    0.000000][    C0] epc : ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30
[    0.000000][    C0]  gp : ffffffff8a3bf240 tp : ffffffff88842080 t0 : ff600000ffab6000
[    0.000000][    C0]  t1 : 000000017fab6000 t2 : 65203a6573726363 s0 : ffffffff88807bc0
[    0.000000][    C0]  s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000
[    0.000000][    C0]  a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000
[    0.000000][    C0]  a5 : ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000
[    0.000000][    C0]  s2 : ff60000000000000 s3 : 0040000000000000 s4 : 0004000000000000
[    0.000000][    C0]  s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 : ffffffff88384d00
[    0.000000][    C0]  s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0
[    0.000000][    C0]  s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20
[    0.000000][    C0]  t5 : ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000
[    0.000000][    C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003
[    0.000000][    C0] [&lt;ffffffff86851c88&gt;] sparse_init+0x58a/0x6fe
[    0.000000][    C0] [&lt;ffffffff8683d396&gt;] mm_core_init_early+0x116/0x1e30
[    0.000000][    C0] [&lt;ffffffff86801edc&gt;] start_kernel+0xd2/0x848

Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment
before using it in VMEMMAP_ADDR_ALIGN.  This keeps the existing
round_down() logic while making the resulting vmemmap base satisfy the
mask-alignment requirement.

Link: https://lore.kernel.org/20260716115326.3466926-1-xujiakai2025@iscas.ac.cn
Fixes: 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
Signed-off-by: Jiakai Xu &lt;xujiakai2025@iscas.ac.cn&gt;
Reviewed-by: Kiryl Shutsemau (Meta) &lt;kas@kernel.org&gt;
Cc: Albert Ou &lt;aou@eecs.berkeley.edu&gt;
Cc: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
Cc: David Hildenbrand &lt;david@kernel.org&gt;
Cc: Guo Ren &lt;guoren@kernel.org&gt;
Cc: Mike Rapoport &lt;rppt@kernel.org&gt;
Cc: Muchun Song &lt;muchun.song@linux.dev&gt;
Cc: Nam Cao &lt;namcao@linutronix.de&gt;
Cc: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Cc: Vishal Moola (Oracle) &lt;vishal.moola@gmail.com&gt;
Assisted-by: YuanSheng:DeepSeek-V4-Flash
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to
VMEMMAP_ADDR_ALIGN.  That alignment must therefore be expressed in the
physical-address domain.

Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
attempted to account for the maximal folio alignment by feeding
MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN.  However,
MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage,
whereas VMEMMAP_ADDR_ALIGN is used to align a physical address.

The mask-based compound_info encoding requires pfn_to_page(0) to be
naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN.  Commit 9f94db4c7eaa
("mm/sparse: check memmap alignment for compound_info_has_mask()") added a
check for that requirement and exposed the unit mismatch on systems such
as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES *
PAGE_SIZE.

Here is the log:
[    0.000000][    C0] ------------[ cut here ]------------
[    0.000000][    C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0
[    0.000000][    C0] Modules linked in:
[    0.000000][    C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT 
[    0.000000][    C0] Hardware name: riscv-virtio,qemu (DT)
[    0.000000][    C0] epc : sparse_init+0x58a/0x6fe
[    0.000000][    C0]  ra : sparse_init+0x58a/0x6fe
[    0.000000][    C0] epc : ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30
[    0.000000][    C0]  gp : ffffffff8a3bf240 tp : ffffffff88842080 t0 : ff600000ffab6000
[    0.000000][    C0]  t1 : 000000017fab6000 t2 : 65203a6573726363 s0 : ffffffff88807bc0
[    0.000000][    C0]  s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000
[    0.000000][    C0]  a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000
[    0.000000][    C0]  a5 : ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000
[    0.000000][    C0]  s2 : ff60000000000000 s3 : 0040000000000000 s4 : 0004000000000000
[    0.000000][    C0]  s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 : ffffffff88384d00
[    0.000000][    C0]  s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0
[    0.000000][    C0]  s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20
[    0.000000][    C0]  t5 : ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000
[    0.000000][    C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003
[    0.000000][    C0] [&lt;ffffffff86851c88&gt;] sparse_init+0x58a/0x6fe
[    0.000000][    C0] [&lt;ffffffff8683d396&gt;] mm_core_init_early+0x116/0x1e30
[    0.000000][    C0] [&lt;ffffffff86801edc&gt;] start_kernel+0xd2/0x848

Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment
before using it in VMEMMAP_ADDR_ALIGN.  This keeps the existing
round_down() logic while making the resulting vmemmap base satisfy the
mask-alignment requirement.

Link: https://lore.kernel.org/20260716115326.3466926-1-xujiakai2025@iscas.ac.cn
Fixes: 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
Signed-off-by: Jiakai Xu &lt;xujiakai2025@iscas.ac.cn&gt;
Reviewed-by: Kiryl Shutsemau (Meta) &lt;kas@kernel.org&gt;
Cc: Albert Ou &lt;aou@eecs.berkeley.edu&gt;
Cc: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
Cc: David Hildenbrand &lt;david@kernel.org&gt;
Cc: Guo Ren &lt;guoren@kernel.org&gt;
Cc: Mike Rapoport &lt;rppt@kernel.org&gt;
Cc: Muchun Song &lt;muchun.song@linux.dev&gt;
Cc: Nam Cao &lt;namcao@linutronix.de&gt;
Cc: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Cc: Vishal Moola (Oracle) &lt;vishal.moola@gmail.com&gt;
Assisted-by: YuanSheng:DeepSeek-V4-Flash
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm</title>
<updated>2026-07-21T15:26:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-07-21T15:26:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b4b760b59fad082671b075f4f1fdac318c633a61'/>
<id>b4b760b59fad082671b075f4f1fdac318c633a61</id>
<content type='text'>
Pull kvm fixes from Paolo Bonzini:
 "RISC-V:

   - Avoid redundant allocations when allocating IMSIC page tables

   - Apply SBI FWFT LOCK flag only on successful set

   - Bound SBI PMU counter mask scan to BITS_PER_LONG, since on RV32 the
     PMU SBI start/stop helper can only access 32 PMU counters.

   - Skip TLB flush when G-stage PTE becomes valid if the Svvptc
     extension is available.

   - Always show Zicbo[m|z|p] block sizes in ONE_REG

   - Inject instruction access fault on unmapped guest fetch

   - Use raw spinlock for irqs_pending and irqs_pending_mask

   - Fix Spectre-v1 in vector register access via ONE_REG

  x86:

   - Fixes to SEV selftests

   - Once free_nested() did a VMCLEAR of shadow VMCS, there's no need to
     VMCLEAR it again if the kernel is preempted and thread migration
     happens

   - Preserve nested TDP shadow page tables if they are used as roots,
     instead of clearing them unnecessarily

   - Fix use of stale data if out-of-memory happens after vendor module
     reload

   - Check for invalid/obsolete root *after* making MMU pages available,
     because the latter can make a page invalid

   - Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN
  KVM: selftests: sev_init2_tests: Derive SEV availability from KVM
  KVM: selftests: sev_smoke_test: Only run VM types the host offers
  KVM: x86/mmu: Fix use-after-free on vendor module reload
  KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots
  KVM: x86: Check for invalid/obsolete root *after* making MMU pages available
  KVM: nVMX: Hide shadow VMCS right after VMCLEAR
  KVM: riscv: Fix Spectre-v1 in vector register access
  RISC-V: KVM: Serialize virtual interrupt pending state updates
  RISC-V: KVM: Inject instruction access fault on unmapped guest fetch
  RISC-V: KVM: Zicbo[m|z|p] block sizes should be always present in ONE_REG
  riscv: kvm: Skip TLB flush when G-stage PTE becomes valid with Svvptc
  KVM: riscv: PMU: Bound counter mask scan to BITS_PER_LONG
  KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
  RISC-V: KVM: Avoid redundant page-table allocations in ioremap topup
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull kvm fixes from Paolo Bonzini:
 "RISC-V:

   - Avoid redundant allocations when allocating IMSIC page tables

   - Apply SBI FWFT LOCK flag only on successful set

   - Bound SBI PMU counter mask scan to BITS_PER_LONG, since on RV32 the
     PMU SBI start/stop helper can only access 32 PMU counters.

   - Skip TLB flush when G-stage PTE becomes valid if the Svvptc
     extension is available.

   - Always show Zicbo[m|z|p] block sizes in ONE_REG

   - Inject instruction access fault on unmapped guest fetch

   - Use raw spinlock for irqs_pending and irqs_pending_mask

   - Fix Spectre-v1 in vector register access via ONE_REG

  x86:

   - Fixes to SEV selftests

   - Once free_nested() did a VMCLEAR of shadow VMCS, there's no need to
     VMCLEAR it again if the kernel is preempted and thread migration
     happens

   - Preserve nested TDP shadow page tables if they are used as roots,
     instead of clearing them unnecessarily

   - Fix use of stale data if out-of-memory happens after vendor module
     reload

   - Check for invalid/obsolete root *after* making MMU pages available,
     because the latter can make a page invalid

   - Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN
  KVM: selftests: sev_init2_tests: Derive SEV availability from KVM
  KVM: selftests: sev_smoke_test: Only run VM types the host offers
  KVM: x86/mmu: Fix use-after-free on vendor module reload
  KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots
  KVM: x86: Check for invalid/obsolete root *after* making MMU pages available
  KVM: nVMX: Hide shadow VMCS right after VMCLEAR
  KVM: riscv: Fix Spectre-v1 in vector register access
  RISC-V: KVM: Serialize virtual interrupt pending state updates
  RISC-V: KVM: Inject instruction access fault on unmapped guest fetch
  RISC-V: KVM: Zicbo[m|z|p] block sizes should be always present in ONE_REG
  riscv: kvm: Skip TLB flush when G-stage PTE becomes valid with Svvptc
  KVM: riscv: PMU: Bound counter mask scan to BITS_PER_LONG
  KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
  RISC-V: KVM: Avoid redundant page-table allocations in ioremap topup
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()</title>
<updated>2026-07-15T17:12:40+00:00</updated>
<author>
<name>Mark Harris</name>
<email>mark.hsj@gmail.com</email>
</author>
<published>2026-07-14T00:30:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5caae1deee89a6582c761d5dcd4b924b744426cc'/>
<id>5caae1deee89a6582c761d5dcd4b924b744426cc</id>
<content type='text'>
When cpusetsize &lt; cpumask_size(), hwprobe_get_cpus() did not fully
initialize its copy of the cpu mask, which could cause non-deterministic
results from the riscv_hwprobe syscall on a system with more than 8 CPUs
when the supplied cpu mask is empty.  Address this by fully initializing
the cpu mask.

Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag")
Signed-off-by: Mark Harris &lt;mark.hsj@gmail.com&gt;
Reviewed-by: Nam Cao &lt;namcao@linutronix.de&gt;
Reviewed-by: Michael Ellerman &lt;mpe@kernel.org&gt;
Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When cpusetsize &lt; cpumask_size(), hwprobe_get_cpus() did not fully
initialize its copy of the cpu mask, which could cause non-deterministic
results from the riscv_hwprobe syscall on a system with more than 8 CPUs
when the supplied cpu mask is empty.  Address this by fully initializing
the cpu mask.

Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag")
Signed-off-by: Mark Harris &lt;mark.hsj@gmail.com&gt;
Reviewed-by: Nam Cao &lt;namcao@linutronix.de&gt;
Reviewed-by: Michael Ellerman &lt;mpe@kernel.org&gt;
Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com
Signed-off-by: Paul Walmsley &lt;pjw@kernel.org&gt;</pre>
</div>
</content>
</entry>
</feed>
