kmi/arch/riscv64/kernel/smp.c, branch masterACTIVE - Kernel with migrating threads as IPChttps://metanimi.dy.fi/cgit/kmi/atom?h=master2024-11-01T08:28:04Zformatting and docs updates2024-11-01T08:28:04ZKimplulkimi.h.kuparinen@gmail.com2024-10-31T12:05:25Zurn:sha1:89e162f3916de5a4faef5bd626590d004bdcdc39smp on visionfive2 'works'2024-11-01T08:27:51ZKimplulkimi.h.kuparinen@gmail.com2024-10-30T14:23:15Zurn:sha1:d5e5afae9249da312b417bc4f5f45ac164404846most of the way to passing tests2024-10-29T22:57:33ZKimplulkimi.h.kuparinen@gmail.com2024-10-29T22:57:33Zurn:sha1:44a73ecab6e91519627786a5101cd4f1a2f2b0d7make sys_create() better + test2024-08-26T16:54:48ZKimplulkimi.h.kuparinen@gmail.com2024-08-26T16:54:48Zurn:sha1:1b5a553194f47066d60bb1c9475af1f413af8f4afix LLVM2024-07-08T15:04:03ZKimplulkimi.h.kuparinen@gmail.com2024-07-08T14:43:59Zurn:sha1:e134202611a50b358c147c92bfb8a7f443030b8b
+ Anything extern is right out as LLVM doesn't produce correct code for
them. Maybe if I added some extra attributes but I'm skeptical.
Replaced with static variables and getters/setters.
+ Inline ASM is apparently a bit buggy, so use an assembly stub when jumping to init.
+ Minimize work done in main() to minimize chance of LLVM doing something silly.
Still not 100% certain that I shouldn't just write the main() as an assembly stub
in arch/riscv64 to be absolutely sure everything works as intended.
+ Make .kernel.start section SHF_ALLOC, otherwise lld complains about
pc-relative addressing
Probably some other stuff as well that I'm forgetting right now. But at least with
LLVM14 LTO seems to work, which is pretty cool?
simplify assertions2024-07-07T04:02:46ZKimplulkimi.h.kuparinen@gmail.com2024-07-07T04:02:46Zurn:sha1:b97967ab660243b723f246db03c2e4a82e125f3f
+ No real point having multiple different levels of assertions, just say
you assert something and be done with it
smp now seems to work2024-07-07T04:00:43ZKimplulkimi.h.kuparinen@gmail.com2024-07-07T04:00:43Zurn:sha1:122374c362ba8bb9082385da3c82e264ab594f15
+ Had some minor issues with a wraparound of size_t that effectively
meant that some regions were allocated twice. Also, booting should be
a bit more reliable now, turned out that the previous iteration of the
booting was just accidentally working due to the kernel being placed
'close enough' in RAM to where it was linked to. Fixed by allocating a
vmem of O1 that maps the kernel to a 2MiB boundary at boot, pretty
nifty.
core bringup + various warnings2024-07-06T20:37:11ZKimplulkimi.h.kuparinen@gmail.com2024-07-06T20:37:11Zurn:sha1:3fedbb6e1f849c5e0a4033d68201d60c2fc48121
+ dbg_fdt() is apparently broken, possibly due to UB or something, but
it causes some issues with optimizations enabled. Remove it
temporarily
move rpc stack handling to arch-specific code2023-10-09T13:15:06ZKimplulkimi.h.kuparinen@gmail.com2023-10-09T11:57:18Zurn:sha1:9c9d589ea310f1290e4d6d2019fc8b51d9a86e42
+ Fairly considerable speedup, as we don't have to look up the rpc pte
every time separately, instead cacheing them. Adds an architecture
specific limitation to total rpc stack size, though.
fix warnings in smp.c2023-08-04T17:56:05ZKimplulkimi.h.kuparinen@gmail.com2023-08-04T17:55:47Zurn:sha1:7d327cbc68f30615b2f15ee403a986e068650b27
+ Only occur with my version of riscv64-linux-gnu-gcc. Funny, that.