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

[Luca]

Il 01/01/24 14:51, Sergey Bugaev ha scritto:
> 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.

Good to hear! so if I understand it correctly you tested it on aarch64 
GNU/Linux?

> 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.

Starting the kernel itself will probably not a problem, thanks to GRUB, 
but it shouldn't be too hard to add support for U-Boot either if needed.

I think more issues might come out setting up the various pieces of the 
system. For example, some chips have heterogeneous cores, (e.g.mine has 
two A72 cores and four A53 cores) so SMP will be more complicated.

Also, about the serial console, it might be useful at some point to use 
a driver from userspace, if we can reuse some drivers from netbsd or 
linux, to avoid embedding all of them in 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?)

You can emulate aarch64 from an amd64 machine, but it's not very 
efficient. Also, I would realay like to run GNU/Hurd natively :)

> 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).

sure, but I'll have to get a bit more familiar with the aarch64 details 
first.

> 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.

AFAIK there are no I/O ports in ARM, the usual way to configure things 
is with memory-mapped registers, so this might become even easier. About 
IRQs, probably it needs to be arch-specific anyway.

> 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?

Do you mean Pointer Authentication Code? That seems quite a new feature, 
so maybe not fundamental to have a first working kernel, but anyway I 
don't see issues in having arch-specific data in tasks.

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

For gnumach, it might be easier to debug on real hw than x86 if we can 
use openocd as gdbserver (but JTAG lines are not always reachable).

For user space tasks I don't know.


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

It could, but also it doesn't seem mandatory, so I would start without it.

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

I think nowadays LKL would be a better target, unless there are drivers 
in netdde used also on aarch64. however AFAIK LKL doesn't support 
aarch64, and it's not yet upstream, so I'd look at rump for drivers first.


Luca