* Implement syscall readlinkat
* Implement syscall readv by read syscalls
Since pk lacks kernel-space dynamic memory management, we implement readv with
normal read syscalls rather than forwarding it to spike
We previously kernel-panicked because that made it more obvious when a
syscall implementation was missing. These days, it's more common that
the C library will do something sensible in response to returning -ENOSYS.
Favor that approach to avoid frustrating users.
The memory manager maintains the first free page as the page after the
`_end` synthetic emitted by the linker. This value is stored in a
translation unit local variable. This value is only ever written to
from `init_early_alloc` which is static and only ever invoked from
`pk_vm_init`. Furthermore, the value that `first_free_page` is ever set
to is computed as a rounding of the _address_ of `_end`. Because the
address of the symbol cannot change during execution of a normal
program, this is effectively a constant, making the computed value a
"constant" which can be re-materialized. Now, with the knowledge that
the value is effectively a constant that can be re-materialized and the
fact that the value is ever written to at a single position, we can
simply re-materialize the value if it was ever changed in
`free_page_addr`. This will allow the 8-byte value to be truncated to
1-byte.
Now, we can inline `__early_pgalloc_align`, and because the combination
of `__early_alloc` and `__early_pgalloc_align` is small, we can inline
that again at the two sites locally. This changes the
`__augment_page_freelist` to re-materialize the constant when needed for
the allocation.
The re-materialization however uses a pc-relative addressing, which now
computes a different value than expected - the address has become a VA
rather than a PA. This results in the address computed by
`free_page_addr` (which is the result of the `__early_pgalloc_align`) to
be a virtual address after the relocation, which then propagates through
`__early_alloc` to the value in `__augment_page_freelist`, which is then
consumed by `__page_alloc`, which will treat the now VA as a PA and
perform an additional translation to a VA.
Mark the value as `volatile` to indicate that the value must be read at
all points to thwart the size optimization of the compiler resulting in
a mis-compilation resulting in the eventual invalid memory access during
the `memset` that follows the allocation.
Thanks to @nzmichaelh for the help in tracking this down!
`SYS_getcwd` is different from `getcwd` in that the return value is < 0
on failure otherwise it is the length of the string. The proxy kernel
was treating 0 as success and all other values as error. As a result,
we would never return a valid value for `getcwd`.
The following program now executes properly with the Proxy Kernel:
```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <linux/limits.h>
int main(int argc, char **argv) {
unsigned char buffer[PATH_MAX + 1] = {0};
if (getcwd(buffer, PATH_MAX))
printf("cwd: %s\n", buffer);
return EXIT_SUCCESS;
}
```
Use of asm aliased register variables in local scope can only be used
for extended assembly parameters. This changes the few instances of
this in the floating point emulation to use the GNU extended assembly
syntax to access the `tp` register. This ensures that we do not rely on
undefined behaviour. This was uncovered when building the Proxy kernel
with clang and LLVM.
The use of `asm` for register aliasing is supported in two different
contexts:
- local variables (including GNU expression statements) where it may
only be used for specifying registers for input and output operands to
extended `asm` syntax.
c.f. https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables
- global variables where it may be used to observe the contents of a
register.
c.f. https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html#Global-Register-Variables
The two options here is to either to hoist the variable out into a
global variable, but then it should not be in a header due to fears of
ODR in case the optimizer does not inline it away, and thus becomes a
bit more tricky. The alternative that this change actually adopts is to
explicitly use a move to copy the value out via the GNU extended
assembly syntax.
With this change, it is now possible to build the Proxy Kernel
completely with clang/LLVM and link with LLD. The generated kernel also
runs under SPIKE and behaves as expected in a simple smoke test (without
any executable prints the expected message, and runs a trivial RVV
example).
This is an equivalent rewrite of the existing code. When building with
gas, the `bltu` would implicitly get relaxed to the `bgeu` + `j`. This
relaxation is required as the `init_other_hart` is not guaranteed to be
addressable in 12-bits. When building with the LLVM IAS instead of gas
we fail to link as the branch is not relaxed. This change enables LLVM
to build and link this code with the LLVM IAS and lld.
The LLVM IAS does not support the older name for the `mtval` CSR. This
updates the name to the current spelling, which is required to build
with the LLVM IAS. This remains compatible with binutils as well.
This replaces use of the old `sbadaddr` CSR name with the current
`stval` name. The old spelling is not supported by the LLVM IAS,
however, the modern spelling is supported by both LLVM and binutils.
Using recent compilers we get the following error message:
../pk/pk.c: In function 'run_loaded_program.constprop':
../pk/pk.c:177:3: error: both arguments to '__builtin___clear_cache'
must be pointers
177 | __clear_cache(0, 0);
| ^~~~~~~~~~~~~~~~~~~
Let's use the existing function __riscv_flush_icache(),
give it a header with a prototype and use it to
emits the FENCE.I instruction directly.
See #239
Suggested-by: Andrew Waterman <andrew@sifive.com>
Signed-off-by: Christoph Muellner <cmuellner@linux.com>
The upstream LiteX project defaults to "litex,liteuart" as the value
for the "compatible" property of the UART DT node, so let's add it to
the current list of accepted strings.
Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
This assumes that stval is populated with the opcode on illegal
instruction exceptions. But since we're only using the opcode for
error reporting, it's OK if this assumption is violated.
Andrew Waterman
mylai-mtk
valentinThomazic
Mark Goncharov
xukl
Kenneth Ostby
MaxXing
Lucheng Zhang
Fangrui Song
Zenithal
Saleem Abdulrasool
Andreas Kuster
John Baldwin
Marcus Comstedt
Saleem Abdulrasool
Christoph Müllner
gsomlo