kmi/arch/riscv64/kernel/entry.S, branch masterACTIVE - Kernel with migrating threads as IPChttps://metanimi.dy.fi/cgit/kmi/atom?h=master2024-11-01T08:27:36Zrpc actually marks and unmarks stack regions2024-11-01T08:27:36ZKimplulkimi.h.kuparinen@gmail.com2024-10-30T11:34:18Zurn:sha1:f139fff6ae7063c1965fa3085bb2585d7d838d72
+ Processes won't be able to read previous stack frames etc
most of the way to passing tests2024-10-29T22:57:33ZKimplulkimi.h.kuparinen@gmail.com2024-10-29T22:57:33Zurn:sha1:44a73ecab6e91519627786a5101cd4f1a2f2b0d7start moving towards threads always being in rpc2024-10-29T19:17:31ZKimplulkimi.h.kuparinen@gmail.com2024-10-29T19:17:31Zurn:sha1:5976ad390a15726c3ddfacf8c8b282c8350f9554speed up ipc_resp a bit2024-08-30T15:50:51ZKimplulkimi.h.kuparinen@gmail.com2024-08-30T15:50:51Zurn:sha1:712a15ce6c5fdf9c5156a5954cd6c3551547037c
+ Skip unwinding stack and just jump directly to userspace
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.
pretty massive virtual memory rewrite2024-07-06T15:14:04ZKimplulkimi.h.kuparinen@gmail.com2024-07-06T15:14:04Zurn:sha1:76517486919657ecadda9867125dc6730f29a5b7
+ The system is now a bit simpler and hopefully easier to understand, while also
extending the shared memory to be 1:N, where there is one owner who
may become a zombie while waiting for the N to die.
implement bkl2024-07-05T18:02:52ZKimplulkimi.h.kuparinen@gmail.com2024-07-05T18:02:52Zurn:sha1:608f44306a6f0d5692f5c81bcbfe7a621ec254ba
+ Start out using big kernel lock, apparently seL4 thinks its good
enough. I might have a go at using a more fair lock, and possibly
moving to more fine-grained locks if I really feel the need to get
scalability up.
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.
add initial smp bringup2023-08-04T17:50:41ZKimplulkimi.h.kuparinen@gmail.com2023-08-04T17:50:41Zurn:sha1:e16f5f81dfb2e97a554ec19b941ec05a7942fd2dstart working on irqs2023-07-31T19:24:29ZKimplulkimi.h.kuparinen@gmail.com2023-07-31T19:24:29Zurn:sha1:6ad1b899ed93f8bc110cdec7a722c8740f9f8d66