kmi - ACTIVE - Kernel with migrating threads as IPC

Age	Commit message (Collapse)	Author
2023-08-04	add initial smp bringup	Kimplul

2023-07-31	add copyright stuff to new files	Kimplul

2023-07-31	start working on irqs	Kimplul

2023-07-27	use nifty variable argument count trick	Kimplul
	+ Found it in newlib. This allows the compiler to more effectively optimize away unnecessary register operations. Applied to both kernel and init.c for a slight speed increase. I really should move init.c to some other repository though, the binary files are starting to get annoying
2023-07-27	add ipc_kick	Kimplul
	+ Tests will have to come later
2023-07-25	simplify fdt reg reading	Kimplul

2023-07-25	simplify populate/probe pmap	Kimplul

2023-06-11	add some clarifications to rpc stack stuff	Kimplul

2023-06-08	add fast userspace return to do_ipc	Kimplul

2023-06-07	slightly improve padding	Kimplul

2023-06-07	slight improvements to building	Kimplul
	+ User can now specify debug, release and assert handling
2023-06-05	give compiler more room to optimize rpc invocation	Kimplul
	+ Try to write arguments to memory as fast as possible to free up some registers that the compiler can then play with. Qemu runs ~1 700 000 rpc's per second, visionfive2 @1GHz (I think) ~800 000.
2023-06-04	slight optimization and brainfart fix	Kimplul

2023-06-04	visionfive2 boots	Kimplul
	+ Make 8250 serial driver more generic + Still TODO: write a tutorial on how to boot on the visionfive2
2023-06-04	visionfive2 boots until debugging is initialized	Kimplul

2023-05-29	start trying to boot on visionfive 2	Kimplul
	+ Not bootable quite yet. Among other things, I couldn't get the current starfive u-boot fork to boot, so try adding support for booting with precompiled u-boot via the `go` command. Initial testing with qemu shows that this should be possible, and if it works, might be useful in the (far) future with other slightly janky SBCs. Also, NS16550 is 8250-based, and I'm really only using the base 8250, so rename and add visionfive 2 uart to list of compatibles. Visionfive 2 is still completely untested.
2023-05-11	arbitrary load address and RAM base detection	Kimplul
	+ Both kind of go hand in hand, made sense to do both at the same time. Some parts feel slightly hacky, the loader works by placing everything on the stack and avoiding global values. Still, seems to work?
2023-05-01	update license stuff	Kimplul

2023-04-30	rename to kmi	Kimplul

2023-01-26	add req_page syscall	Kimplul

2023-01-16	make process ids signed	Kimplul
	+ Unlikely to ever run into billions of threads, and this keeps in line with stuff like Linux. Also allows C to relatively painlessly implement hashmaps of pids, if neccessary.
2022-12-02	remove MR_SHARED	Kimplul
	+ The new shared memory plan doesn't need it.
2022-12-02	initial shared memory working	Kimplul

2022-12-01	start looking into memory handling	Kimplul
	+ Now 10M alloc/frees succeed, which totals more memory than the virtual machine has, so no too obvious leaks are occuring. For future debugging speed, changed 10M to 1M. + Also quick fix to rpcs, stacks are now assigned. Not entirely sure why they worked before this, but good that I found it.
2022-11-21	make syscall handlers void	Kimplul

2022-11-21	fix formatting	Kimplul

2022-11-21	possible optimisations	Kimplul

2022-11-13	give symbolic name to rpc stack ratio	Kimplul

2022-11-13	outline rpc stack handling	Kimplul

2022-11-13	improve documentation on new features	Kimplul

2022-11-13	~1.3M ipc requests	Kimplul
	+ The secret is using gravestones. I'll have to write up full documentation for the feature but essentially riscv lets us encode whatever we want into page table entries, as long as they're not active. We use this to encode highest user address that is not a zero, in that all entries in the top level are either active or gravestones. When an active entry is removed, it is either a gravestone (if there are other active entries above it) or it starts a cascade of removing entries that have been previously removed Slight runtime overhead to page mapping, pretty major advantage in rpc calls. Feature will need to be tested more thorougly, and the init program is sort of a best scenario with just one top level userspace page table entry active at a time, leading to incredibly fast context switches. Current implementation limits a process' max virtual memory to 248 GiB (in Sv39), but I don't think the missing 8 GiB is that big of a deal.
2022-11-13	~700k ipc requests	Kimplul
	+ Eliminated need for save/load_regs, now the register save area is behind a pointer which _slightly_ increases overall syscall delay, but speeds up ipc requests by a fair bit.
2022-11-13	write init more sensibly	Kimplul
	+ Both easier to look at and now the userspace doesn't play as big of a role in the 'benchmarking' with optimizations turned on.
2022-11-12	slight optimization	Kimplul

2022-11-12	initial rpc implementations	Kimplul

2022-11-11	less buggy fork	Kimplul
	+ Not strictly done yet, but we can swap between two processes :D
2022-11-10	initial implementation of process copying	Kimplul
	+ Not actually working (at least fully), need to continue debugging when I have time.
2022-11-09	update docs	Kimplul

2022-11-09	add basic IPI structure	Kimplul

2022-10-29	rewrite pmem	Kimplul

2022-10-22	create impl and CAP_PROC checking	Kimplul

2022-10-22	initial high level fork imp	Kimplul

2022-10-21	beautification	Kimplul

2022-10-21	initial implementation of swap	Kimplul
	+ Slightly unsure if it should be a syscall, or if assign would be enough. Also, which thread should run in a fork/spawn? For now, old thread, though this might increase latency. Or add swap flag to these calls?
2022-10-21	initial spawn implementation	Kimplul

2022-10-14	add spawn syscall	Kimplul
	+ Prefer over unixy fork/exec for speed since I don't want to support cow. Shell redirection should be done with env server and cooperating libc.
2022-10-14	remove references to cow	Kimplul
	+ Skip cow for now, maybe implement later but try to keep things simple.
2022-09-23	add notify_state to tcb	Kimplul

2022-09-23	remove user data from sys_ipc_notify	Kimplul
	+ Multiple notify signals at the same time, or queued ones waiting for ipc_req/fwd to finish would require a notify stack of some kind, which is maybe too complex for my liking. Not impossible by any means, but I want to keep things simple. Let's say a client wants the server to do some async operation. First, the client calls ipc_req to inform the server that it would like the operation to be done. The server sets this task in some work queue or whatever, and returns to the client as quickly as possible. Later on, when the task is finished, the server does a ipc_req to the client, with data about what was just finished. The client is responsible for noting this data down somewhere, either reacting to the operation directly in the callback, or calling ipc_notify to the thread that requested the operation. Other possible notifications at the same time should be handled at the same time, whichever way the client wants to handle them. Note that ipc_notify triggers only when the thread it targets is in its base state, i.e. not doing an ipc_req. This makes things a bit easier.
2022-09-22	add assign syscall skeleton	Kimplul