| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
* aarch64/include/mach/aarch64/mach_aarch64.defs: (hwcaps_t) make type an
array of uint64_t.
* aarch64/include/mach/aarch64/mach_aarch64_types.h (hwcaps_t) make type a
pointer to uint64_t
Acked-by: Sergey Bugaev <bugaevc@gmail.com>
Message-ID: <20250109224057.1652-1-dnietoc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notes:
* TPIDR_EL0, the TLS pointer, is included in the generic state directly.
* TPIDR2_EL0, part of the SME extension, is not included in the generic
state. If we add SME support, it will be a part of something like
aarch64_sme_state.
* CPSR is not a real register in AArch64 (unlike in AArch32), but a
collection of individually accessible bits and pieces from PSTATE.
Due to how the kernel accesses user mode's PSTATE (via SPSR), it's
convenient to represent PSTATE as a pseudo-register in the same
format as SPSR. This is also what QEMU and XNU do.
* There is no hardware-enforced 'natural' order to place the registers
in, since no registers get pushed onto the stack on exception entry.
Saving and restoring registers from an instance of struct
aarch64_thread_state is implemented entirely in software, and the
format is essentially arbitrary.
* aarch64_float_state includes registers of a 128-bit type; this may
create issues for compilers other than GCC.
* fp_reserved is not a register, but a placeholder. If and when Arm
adds another floating-point meta-register, this will be changed to
represent it, and that would not be considered a compatibility break,
so don't access fp_reserved by name, or its value, from userland.
Instead, memset the whole structure to 0 if starting from scratch, or
memcpy an existing structure.
More thread state types could be added in the future, such as
aarch64_debug_state, aarch64_virt_state (for hardware-accelerated
virtualization), potentially ones for PAC, SVE/SME, etc.
Message-ID: <20240415090149.38358-8-bugaevc@gmail.com>
|
| |
|
|
|
|
|
| |
A few yet-unimplemented codes are also sketched out; these are included
so you know roughly what to expect once the missing functionality gets
implemented, but are not in any way stable or usable.
Message-ID: <20240415090149.38358-7-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
This currently contains a single RPC to get Linux-compatible hwcaps,
as well as the values of MIDR_EL1 and REVIDR_EL1 system registers.
In the future, this is expected to host the APIs to manage PAC keys,
and possibly some sort of AArch64-specific APIs for userland IRQ
handlers.
Message-ID: <20240415090149.38358-6-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
And make it so that the generic vm_param.h doesn't require the machine-
specific one to define PAGE_SIZE etc. We *don't* want a PAGE_SIZE
constant to be statically exported to userland; instead userland should
initialize vm_page_size by querying vm_statistics(), and then use
vm_page_size.
We'd also like to eventually avoid exporting VM_MAX_ADDRESS, but this is
not feasible at the moment. To make it feasible in the future, userland
should try to avoid relying on the definition where possible.
Message-ID: <20240415090149.38358-5-bugaevc@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
We use largely the same ABI as Linux: a syscall is invoked with the
"svc #0" instruction, passing arguments the same way as for a regular
function call. Specifically, up to 8 arguments are passed in the x0-x7
registers, and the rest are placed on the stack (this is only necessary
for the vm_map() syscall). w8 should contain the (negative) Mach trap
number. A syscall preserves all registers except for x0, which upon
returning contains the return value.
Message-ID: <20240415090149.38358-4-bugaevc@gmail.com>
|
|
|
This adds "aarch64" host support to the build system, along with some
uninteresting installed headers. The empty aarch64/aarch64/ast.h header
is also added to create the aarch64/aarch64/ directory (due to Git
peculiarity).
With this, it should be possible to run 'configure --host=aarch64-gnu'
and 'make install-data' successfully.
Message-ID: <20240415090149.38358-3-bugaevc@gmail.com>
|
