Palmer Dabbelt
Posts
169Following
137Followers
144
Palmer Dabbelt
palmer
Apparently the reason my internet's been so flaky lately is because a squirrel has been chewing on my fiber.
0
0
2
Palmer Dabbelt
repeated
repeated
Conor Dooley
conor
# v6.3 linux-riscv recap thing
For v6.2's release, I had to go back and dig through the PRs to figure out what had changed in the
release, so I figured for v6.3 I would try and keep on top of the PRs as they went out.
So here's one I prepared earlier I guess!
Perhaps the biggest change for v6.3 is the addition (finally!) of the devicetrees for the various
Allwinner D1 based platforms. There's been a bunch of people involved in that support, including
Heiko who worked on the T-HEAD cpu support, but Samuel Holland did the lions share of the work on
the Allwinner parts of that. I think Arnd pointed out that that amounted to 10 boards?
(Reading this back now, feels like they've been in far longer!)
Bit of business-as-usual for the other vendors, a new dev board for Microchip and some minor changes
on the Renesas stuff now - a negative diffstat actually, as some /delete-node/ macros were removed
from the devicetree as support arrived in drivers for the RZ/Five.
Across the kernel, the bits of support for the JH7110 have started to land, including the mmc,
pinctrl and pmu (that being power management, not perf) drivers.
As for architectural changes in v6.3, things mostly centred around text patching and the handling of
extensions, with work from Heiko Stuebner & Jisheng Zhang *dominating* the first RISC-V PR[0] for
the merge window.
Firstly, Jisheng overhauled how we handle enabling extensions. Since a kernel must be able to run
on all hardware, regardless of what (additional) extensions it supports, we need to enable that
code at runtime. To do so in an efficient manner, we patch the kernel at runtime, during early
boot[1]. This mechanism is called "alternatives" Previously, we stored the absolute addresses of the
"standard" code & the extension's replacement version of that operation, and Jisheng converted that
to use relative addresses instead. All that work, in a complex corner of the kernel (IMO!) just so
that we can use ISA extensions properly in the VDSO!
They also squeezed in some cleanup of our linker script into their schedule somehow..
Heiko then had another big patchset, refactoring extension handling with the aim of allowing
function calls in these "alternatives", so that we can use the Zbb bit manipulation extension in
string comparison routines. Zbb is present on the StarFive JH7110, so, once the devicetrees & clock
drivers etc land for that platform you can go test it out if you have a VisionFive 2.
Unfortunately between those series, a lot changed and the inevitable bugs surfaced, the most serious
of which (preventing boot, mounting a rootfs etc) were fixed before -rc1 by Samuel and Björn Töpel!
Other than those, the first PR also featured:
- Ftrace optimisations from Guo Ren, the first couple patches from a larger series he has been
working on for some months.
- A fix from Andy Chiu, that's been in the works since Linux Plumbers, that caused panics in ftrace
relating to disabling preemption.
- Another one that's been in the works since Plumbers, RISC-V previously had a mix of SOC_ and ARCH_
symbols for vendors, depending on whether a vendor had prior support in other architectures. There
are now ARCH_ versions of the SOC_ symbols as part of an effort to gradually convert everything to
ARCH_ to match what is done in other parts of the kernel.
- Splat decoding support for RISC-V in the decodecode script, from Björn Töpel.
- Sergey Matyukevich upstreamed part of a fix for a tricky looking cache update bug, that seems to
occur on uniprocessor systems running CONFIG_SMP=y kernels.
In the netdev PR, which is where bpf patches for RISC-V (and other archs) get into mainline, Pu
Lehui landed support for both the bpf trampoline and 64-bit kfunc support. Björn seemed pretty happy
about that, so it must be important!
The second PR, as might be expected, was substantially smaller. It did bring with it a KASAN rework
from Alex Ghiti, aiming to substantially simplify what he described as RISC-V's "intricate"
implementation and a bump in COMMAND_LINE_SIZE that should allow syzbot to start fuzzing RISC-V.
In terms of fixes, we got yet another round of fixes for handling the (highly frustrating) decision
to move the csr and fence.i instructions out of the I extension, specifically for mixed toolchains
where some components pre-date that move.
As of -rc3, the most interesting fix this cycle was from Sergey Matyukevich, reverting some
ill-fated changes of his for flushing stale TLB entries and replacing them with another fix.
As far as I can tell from reading the patches, the issue was mainly hit on uniprocessor systems
running SMP kernels - at least the drawn out discussion certainly featured discussion of that
configuration!
Nathan Chancellor took over a bit of work I was doing, the nth patchset of late that has to deal
with the fallout of RVI's decision to move some instructions out of the base I extension.
Great craic really.
A fairly "major" fix for how late in the game it came was Alex Ghiti's conversion of RISC-V back
to using the fixmap for dtb mapping. It was moved out of the fixmap in 2020, with the logic that it
was not actually needed & wasted a lot of space.
However, I ran into some issues where either:
a) reserved memory node names would use "early" virtual
addresses (and thus cause a panic when accessed in a driver)
b) reservation was done too late to prevent early memblock allocations being done in a section of
reserved memory. This would cause the reservation to fail, a bit of an issue if that memory is
not actually usable by the kernel...
The most straightforward thing was to just move back to using the fixmap & sidestep the issue.
Thanks to Alex for doing something promptly & saved me significant time flailing around if I had had
to do it myself!
Of course there were a bunch of other various fixes, with several focusing on different bits of TLB,
and some for the text patching code that had recently been changed by Jisheng et al.
One of those fixes being because somehow we all forgot that the aforementioned alternatives
framework is not always enabled, and if it wasn't the FPU could not be used!
0 - https://lore.kernel.org/all/mhng-9df18be9-c02d-41f8-93ee-7e1e124a31ec@palmer-ri-x1c9/
1 - We also do it when modules are loaded
For v6.2's release, I had to go back and dig through the PRs to figure out what had changed in the
release, so I figured for v6.3 I would try and keep on top of the PRs as they went out.
So here's one I prepared earlier I guess!
Perhaps the biggest change for v6.3 is the addition (finally!) of the devicetrees for the various
Allwinner D1 based platforms. There's been a bunch of people involved in that support, including
Heiko who worked on the T-HEAD cpu support, but Samuel Holland did the lions share of the work on
the Allwinner parts of that. I think Arnd pointed out that that amounted to 10 boards?
(Reading this back now, feels like they've been in far longer!)
Bit of business-as-usual for the other vendors, a new dev board for Microchip and some minor changes
on the Renesas stuff now - a negative diffstat actually, as some /delete-node/ macros were removed
from the devicetree as support arrived in drivers for the RZ/Five.
Across the kernel, the bits of support for the JH7110 have started to land, including the mmc,
pinctrl and pmu (that being power management, not perf) drivers.
As for architectural changes in v6.3, things mostly centred around text patching and the handling of
extensions, with work from Heiko Stuebner & Jisheng Zhang *dominating* the first RISC-V PR[0] for
the merge window.
Firstly, Jisheng overhauled how we handle enabling extensions. Since a kernel must be able to run
on all hardware, regardless of what (additional) extensions it supports, we need to enable that
code at runtime. To do so in an efficient manner, we patch the kernel at runtime, during early
boot[1]. This mechanism is called "alternatives" Previously, we stored the absolute addresses of the
"standard" code & the extension's replacement version of that operation, and Jisheng converted that
to use relative addresses instead. All that work, in a complex corner of the kernel (IMO!) just so
that we can use ISA extensions properly in the VDSO!
They also squeezed in some cleanup of our linker script into their schedule somehow..
Heiko then had another big patchset, refactoring extension handling with the aim of allowing
function calls in these "alternatives", so that we can use the Zbb bit manipulation extension in
string comparison routines. Zbb is present on the StarFive JH7110, so, once the devicetrees & clock
drivers etc land for that platform you can go test it out if you have a VisionFive 2.
Unfortunately between those series, a lot changed and the inevitable bugs surfaced, the most serious
of which (preventing boot, mounting a rootfs etc) were fixed before -rc1 by Samuel and Björn Töpel!
Other than those, the first PR also featured:
- Ftrace optimisations from Guo Ren, the first couple patches from a larger series he has been
working on for some months.
- A fix from Andy Chiu, that's been in the works since Linux Plumbers, that caused panics in ftrace
relating to disabling preemption.
- Another one that's been in the works since Plumbers, RISC-V previously had a mix of SOC_ and ARCH_
symbols for vendors, depending on whether a vendor had prior support in other architectures. There
are now ARCH_ versions of the SOC_ symbols as part of an effort to gradually convert everything to
ARCH_ to match what is done in other parts of the kernel.
- Splat decoding support for RISC-V in the decodecode script, from Björn Töpel.
- Sergey Matyukevich upstreamed part of a fix for a tricky looking cache update bug, that seems to
occur on uniprocessor systems running CONFIG_SMP=y kernels.
In the netdev PR, which is where bpf patches for RISC-V (and other archs) get into mainline, Pu
Lehui landed support for both the bpf trampoline and 64-bit kfunc support. Björn seemed pretty happy
about that, so it must be important!
The second PR, as might be expected, was substantially smaller. It did bring with it a KASAN rework
from Alex Ghiti, aiming to substantially simplify what he described as RISC-V's "intricate"
implementation and a bump in COMMAND_LINE_SIZE that should allow syzbot to start fuzzing RISC-V.
In terms of fixes, we got yet another round of fixes for handling the (highly frustrating) decision
to move the csr and fence.i instructions out of the I extension, specifically for mixed toolchains
where some components pre-date that move.
As of -rc3, the most interesting fix this cycle was from Sergey Matyukevich, reverting some
ill-fated changes of his for flushing stale TLB entries and replacing them with another fix.
As far as I can tell from reading the patches, the issue was mainly hit on uniprocessor systems
running SMP kernels - at least the drawn out discussion certainly featured discussion of that
configuration!
Nathan Chancellor took over a bit of work I was doing, the nth patchset of late that has to deal
with the fallout of RVI's decision to move some instructions out of the base I extension.
Great craic really.
A fairly "major" fix for how late in the game it came was Alex Ghiti's conversion of RISC-V back
to using the fixmap for dtb mapping. It was moved out of the fixmap in 2020, with the logic that it
was not actually needed & wasted a lot of space.
However, I ran into some issues where either:
a) reserved memory node names would use "early" virtual
addresses (and thus cause a panic when accessed in a driver)
b) reservation was done too late to prevent early memblock allocations being done in a section of
reserved memory. This would cause the reservation to fail, a bit of an issue if that memory is
not actually usable by the kernel...
The most straightforward thing was to just move back to using the fixmap & sidestep the issue.
Thanks to Alex for doing something promptly & saved me significant time flailing around if I had had
to do it myself!
Of course there were a bunch of other various fixes, with several focusing on different bits of TLB,
and some for the text patching code that had recently been changed by Jisheng et al.
One of those fixes being because somehow we all forgot that the aforementioned alternatives
framework is not always enabled, and if it wasn't the FPU could not be used!
0 - https://lore.kernel.org/all/mhng-9df18be9-c02d-41f8-93ee-7e1e124a31ec@palmer-ri-x1c9/
1 - We also do it when modules are loaded
2
15
14
Palmer Dabbelt
palmer
Turns out my shift cable was broken, but it gave me an excuse to get the tanpan setup and it's working way better I'd expected so far...
0
0
2
Palmer Dabbelt
repeated
repeated
K. Ryabitsev
monsieuricon
Join me for LSS NA 2023! See me talk on a boring non-controversial topic. Enjoy Vancouver in May!
https://lssna2023.sched.com/event/1K7ao/how-to-backdoor-the-linux-kernel-and-fail-konstantin-ryabitsev-the-linux-foundation
https://lssna2023.sched.com/event/1K7ao/how-to-backdoor-the-linux-kernel-and-fail-konstantin-ryabitsev-the-linux-foundation
2
5
11
Palmer Dabbelt
repeated
repeated
K. Ryabitsev
monsieuricon
Is there one of those German words for feeling glad that your conference talk got accepted, but experiencing a growing sense of dread as the slides submission due date creeps closer every day?
Asking for a friend.
Asking for a friend.
3
1
7
Palmer Dabbelt
repeated
repeated
K. Ryabitsev
monsieuriconI just released b4 0.12.2:
- prep: add ability to use markdown in the cover content (requires escaping the leading “#” as “>#” that is stripped on cover letter rendering)
- send: don’t require vN to –resend (will resend the latest version)
- test: don’t require running from git
- plus several bugfixes mostly dealing with corner-case conditions
https://lore.kernel.org/tools/20230310205933.yumi2udfqrfubccg@meerkat.local/
0
3
8
Palmer Dabbelt
repeated
repeated
Conor Dooley
conor
With v6.2 being released the other day, I did a bit of a recap to remind myself of what actually
landed this time around for RISC-V. Figured I may as well share it /shrug
With the V2 on the horizon, Cristian Ciocaltea added the VisionFive v1 DT, which has been a long
time coming! Unfortunately, that platform is still not really supported in mainline and may never
get there given it's reliance on non-coherent DMA that is yet to be supported.
He did post some of the out of tree non-coherent dma patches on the list the other day though, and
while that's unlikely to land anytime soon, I hope it gets there eventually :)
Renesas finally joined the RISC-V party for v6.2, with Geert's PR adding the base DT for the
RZ/Five. This platform *also* relies on non-coherent DMA to be fully supported, but that is
currently a work in progress! That work was done by Lab Prabhakar from Renesas.
Palmer's PR is where the actually interesting stuff happens though...
Binglei Wang added support for rethooks, after a rough start with mailer issues!
Drew Jones, while not reviewing, worked on some nice cleanups to alternatives and extension
handling.
Anup got one of his many new-feature support series over the line for PMEM support.
The T-Head c9xx series cores got support for their non-standard PMU variant upstream thanks to
Heiko who has been somewhat of a champion for that platform.
RV32, not to be left out, landed support for dynamic ftrace. That work was carried out by Jamie
Iles, who, as the 32-bit bpf maintainer, clearly has an interest in that part of the arch.
Support for zstd compressed images gained support also, thanks to the work of Jisheng Zhang.
Tong Tiangen extended support for hugepages, Xianting Tian got the remainder of their
VMCOREINFO series over the line & Lui Shixin got HUGE\_VMA{P,LLOC} support enabled.
Jinyu Tang brought in support for updating the tlb & Hal Feng put the finishing touch on the base
support for the VisionFive v1 by added the serial driver for it.
Notable also is a patch from Cleo John, tidying up some styling, as it was their first :)
A whole bunch of others contributed various bits of cleanup and fixes that landed in the v6.2, PR
and for more on those check out the changelog in Palmer's PR:
https://lore.kernel.org/linux-riscv/mhng-f76eb33c-7cc1-426f-8f29-37f6bb78baec@palmer-ri-x1c9/
There were also 4 fixes PRs sent out over the course of the merge window, however none of these
really contained anything particularly significant. A lot of attention recently has been centred
around text patching, so it is no surprise that a number of the fixes are there too, with, out of
the 16 total patches in -fixes, 5 were in this area. Other than that, we had a good few general
correctness bits, for sparse warnings etc
landed this time around for RISC-V. Figured I may as well share it /shrug
With the V2 on the horizon, Cristian Ciocaltea added the VisionFive v1 DT, which has been a long
time coming! Unfortunately, that platform is still not really supported in mainline and may never
get there given it's reliance on non-coherent DMA that is yet to be supported.
He did post some of the out of tree non-coherent dma patches on the list the other day though, and
while that's unlikely to land anytime soon, I hope it gets there eventually :)
Renesas finally joined the RISC-V party for v6.2, with Geert's PR adding the base DT for the
RZ/Five. This platform *also* relies on non-coherent DMA to be fully supported, but that is
currently a work in progress! That work was done by Lab Prabhakar from Renesas.
Palmer's PR is where the actually interesting stuff happens though...
Binglei Wang added support for rethooks, after a rough start with mailer issues!
Drew Jones, while not reviewing, worked on some nice cleanups to alternatives and extension
handling.
Anup got one of his many new-feature support series over the line for PMEM support.
The T-Head c9xx series cores got support for their non-standard PMU variant upstream thanks to
Heiko who has been somewhat of a champion for that platform.
RV32, not to be left out, landed support for dynamic ftrace. That work was carried out by Jamie
Iles, who, as the 32-bit bpf maintainer, clearly has an interest in that part of the arch.
Support for zstd compressed images gained support also, thanks to the work of Jisheng Zhang.
Tong Tiangen extended support for hugepages, Xianting Tian got the remainder of their
VMCOREINFO series over the line & Lui Shixin got HUGE\_VMA{P,LLOC} support enabled.
Jinyu Tang brought in support for updating the tlb & Hal Feng put the finishing touch on the base
support for the VisionFive v1 by added the serial driver for it.
Notable also is a patch from Cleo John, tidying up some styling, as it was their first :)
A whole bunch of others contributed various bits of cleanup and fixes that landed in the v6.2, PR
and for more on those check out the changelog in Palmer's PR:
https://lore.kernel.org/linux-riscv/mhng-f76eb33c-7cc1-426f-8f29-37f6bb78baec@palmer-ri-x1c9/
There were also 4 fixes PRs sent out over the course of the merge window, however none of these
really contained anything particularly significant. A lot of attention recently has been centred
around text patching, so it is no surprise that a number of the fixes are there too, with, out of
the 16 total patches in -fixes, 5 were in this area. Other than that, we had a good few general
correctness bits, for sparse warnings etc
1
11
8
Palmer Dabbelt
palmer
CNX's review of the Vision Five 2: https://www.cnx-software.com/2023/02/12/starfive-visionfive-2-sbc-review-debian-12/
2
1
4
Palmer Dabbelt
palmer
After spending the morning trying to figure out how this Documentation patch could possibly cause boot hangs, it turns out I'm just out of disk space...
0
0
8
Palmer Dabbelt
repeated
repeated
K. Ryabitsev
monsieuricon
Are you someone who has a simple fix for something in the Linux kernel, but haven't bothered submitting a patch because you find the email workflow daunting? Can be a bugfix, spelling correction, anything at all.
If so, I want to talk to you! I have tools that simplify this process quite a bit, but I need more feedback from people who aren't long-term Linux maintainers.
Please reach out, either via here or by emailing mricon@kernel.org.
If so, I want to talk to you! I have tools that simplify this process quite a bit, but I need more feedback from people who aren't long-term Linux maintainers.
Please reach out, either via here or by emailing mricon@kernel.org.
9
442
335
Palmer Dabbelt
palmer
I never thought I’d pay more than the face value for a coin, but I couldn’t believe this was real without seeing one in person.
0
1
3