Re: aarch64-gnu (and Happy New Year!)

[Sergey Bugaev]

On Mon, Jan 1, 2024 at 4:02 PM Luca <luca@orpolo.org> wrote:
> Hi Sergey,

Hi Luca,

> Really great work! To work on gnumach we just need MIG and any armv8
> compiler (also targeting GNU/Linux is fine), and it seems MIG works fine
> without adjustments? Maybe there could be some issues once it's run
> somewhere, e.g. alignment issues.

Well, I have the aarch64-gnu toolchain here, please see the binutils &
GCC patches that I posted. But yeah, any aarch64-targeting compiler
should work for gnumach, including aarch64-linux-gnu or just a generic
embedded aarch64 target.

MIG seems to just work (thanks to all the Flávio's work!). I'm using
the same message ABI as on x86_64, and haven't seen any issues so far
— neither compiler errors / failed static assertions (about struct
sizes and such), nor hardware errors from misaligned accesses.

Once I post the preliminary gnumach patches, you should be able to
build a complete binutils + GCC + MIG aarch64-gnu toolchain.

> Another issue with ARM in general is that the hardware support is much
> less streamlined than x86, although with v8 there should be some
> alignment on basic stuff like IRQ and UEFI.

So I've heard, yeah. But yeah I've also heard that newer chips support
UEFI, and from UEFI it should be possible to boot GRUB and from there
gnumach, so maybe the boot process is not as much of a problem as it
was, and we could avoid separate per-board builds of gnumach.

But as always, I have no idea what I'm talking about.

> Probably even the serial
> console needs a platform-specific driver (I'm not sure, I'm more
> familiar with older and more embedded variants like Cortex-M)
>
> To bootstrap gnumach the first thing we'd need would probably be the
> console, setting up the virtual memory, then thread states, context
> switch, irqs and userspace entry points (list by no means exhaustive).
>
> I actually have an armv8 server that would be handy for some
> development, so I might be able to help with something in the future.

Sounds great! (But you should also be able to use qemu, no?)

Even before you write any code, it would be great if you helped review
my gnumach patches (e.g. aarch64_thread_state & the arm/aarch64
exceptions).

Also, there is a bunch of design work to do.

Will/can AArch64 use the same mechanism for letting userland handle
interrupts? Do we have all the mechanisms required for userland to
poke at specific addresses in memory (to replace I/O ports)? — I
believe we do, but I haven't looked closely.

What should the API for manipulating PAC keys look like? I kind of
want it to be just another flavor of thread state, but then it is
really supposed to be per-trask, not per-thread, and maybe adding some
aarch64-specific RPCs to read and write the PAC keys in
mach_aarch64.defs is the right way. But also AFAICS Mach currently has
no notion of per-task arch-specific data (unlike for threads, and
other than the VM map), so it'd be interesting to add one — could it
be useful for something else?

What are the debugging facilities available on ARM / AArch64? Should
we expose them as more flavors of thread state, or...? What would GDB
need?

Should gnumach accept tagged addresses (like PR_SET_TAGGED_ADDR_CTRL on Linux)?

Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on AArch64?

Sergey