| Age | Commit message (Collapse) | Author |
|---|
|
+ Current setup will likely not last long, just a stopgap until I figure
out how I want to build each testcase etc.
Probably dir based, but I'll probably add some scripts that generate
the build rules for each test case (or binary?). Also, should probably
put ouput files in a build directory and keep the source clean, but
again, good enough for now.
Will have to start implementing more extensive tests, and probably
come up with some way to compare textual output etc.
|
|
+ A reserved area is an area at the start of the region that should not
be used unless explicitly asked for, for example null pages.
As such, a small correction to my previous commit message: There's no
danger in not locking req_mem() etc, as a null page will only be
allocated when explicitly asked for.
|
|
+ User has to 'free' the 0 page before it becomes accessible to mapping.
Probably worth noting that this is likely VERY niche and mainly
concerns stuff like certain kinds of emulators that I'm still
eons from implementing, but still.
Unbacked pages can also be useful for some kinds of notifications,
like 'if someone writes to this page, please report it to me with this
ID' or whatever, I remember seeing some discussion about it somewhere
but that's also not really relevant for the moment.
Most significantly, at least with the current design,
after the null page is freed it becomes available for use to regular req_mem()
calls, so users should probably using locks around memory requests.
That's probably a good idea anyway as internally the kernal has to
lock the virtual memory, and without a scheduler it might cause
threads to spin for a while in the kernel which is rather bad.
|
|
+ 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?
|
|
+ Can be used to pass contiguous memory regions to things like virtio
block devices for implementing disk drivers etc.
|
|
+ Effectively means that all executables can be called into, but if an
exe doesn't want to deal with anyone else it should just set a flag
like `not_really_a_server` or whatever
|
|
+ Align kernel to 2MiB boundary in u-boot
+ Optimize alignment functions a little bit, should still have to check
on real hardware but 'feels' more clean
+ Add early boot debugging
+ Put extra cores we aren't ready to account for to sleep if/when they
boot.
+ Make BASE_PAGE_SIZE constant on riscv64/32, helps the compiler with
some alignment checks among other things.
|
|
+ No real point having multiple different levels of assertions, just say
you assert something and be done with it
|
|
+ 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.
|
|
+ Apparently dbg_fdt() itself wasn't buggy, but for whatever reason GCC
produced an absolute load to the prefix string in __print_prefix()
which caused all the issues. Unclear why, seems like a compiler bug.
This commit is more of a workaround, I'd still like to investigate
this further.
|
|
+ Slightly more overhead but will help track down possible memory leaks
in the future. Could also add in a flag for turning off/on but I don't
think the difference in performance is that significant.
|
|
|
|
+ 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.
|
|
+ Took some fairly significant changes, for one the kernel is no longer
relocated at the start of a boot, instead it sits wherever the user
decides the kernel should sit. Similarly, the initial kernel stack and
page table are stored within the binary, slightly bloating the size
but making it much safer to boot since there's really no chance of us
overwriting the fdt or initrd in memory.
|
|
+ Still largely untested, should really try to come up with a proper
testsuite, at the moment it's mostly me trying things out in the (as
of yet unreleased) kmx repo
|
|
+ Terminology is still a bit poor, and will still have to write
documentation + implement ipis properly
|
|
+ The number of allowed threads running at the same time is limited to
num_tids, but each thread's ID can be any larger than that. This
should make ID reuse a lot more rare, and probably makes certain kinds
of time-of-check-to-time-of-use attacks more difficult
|
|
|
|
|
|
+ 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
|
|
+ Tests will have to come later
|
|
+ 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.
|
|
|
|
|
|
+ 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.
|
|
+ RELEASE=1 doesn't work for some reason, though
|
|
+ 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?
|
|
|
|
|
|
|
|
|
|
+ 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.
|
|
|
|
+ Both easier to look at and now the userspace doesn't play as big of a
role in the 'benchmarking' with optimizations turned on.
|
|
|
|
|
|
+ Not strictly done yet, but we can swap between two processes :D
|
|
+ Not actually working (at least fully), need to continue debugging when
I have time.
|
|
+ In total, a syscall is built up of 6 values, with the first being the
syscall number. Symmetrically, the first value is now a status and the
following five values return "values". This allows us to cram in more
info into the ipc_* functions. The performance difference is
absolutely minimal, at least from my testing in qemu.
|
|
|
|
+ Note that it is NOT intended for end user usage, just for debugging.
|
|
|
|
+ Prepare for possibly testing rv32
+ Also remove newline from debugging output
|
|
+ May warn about PHDR not being in LOAD, there is a flag to silence it
(--no-warn-rwx-segment) but it doesn't seem to exist in
riscv64-unknown-elf for some reason.
|
|
+ Doesn't seem to be specified anywhere, but I'll stick with 2MB for
now, working on the assumption that the FW is at the start of the
physical RAM.
Possible TODOs: generate apos.its automatically from init.elf,
allocate root_branch statically?
|
|
|
|
|
|
+ Still lots todo, and I'm not entirely sure how I should handle program
space switches (mainly since the kernel uses the process' stack, maybe
it shouldn't?)
|
|
+ Release mode is sort of broken, as lto doesn't work with linker
relaxation and turning the relaxation off causes issues with the jump
from init to kernel (as I've currently implemented it, could probably
be fixed with a manual jump from assembly, I'll add it to my TODO
list)
|
