powerpc: Add first Linuxulator support (ELFv1, BE, powerpc64)

[jhibbits]

Summary

Introduce the first cut of the Linuxulator for powerpc64. This was a
GSoC project for 2022, and consists of the following:

• Big-endian powerpc64
• ELFv1
• Limited shared page (no timekeep)
• Most, if not all, syscalls are implemented, all common ones, no arch-specific ones.

At completion of the GSoC period this was able to run through the LTP
test suite, with a very high pass rate. More work remains, as always,
and will be done as needed.

Further work is still necessary, but this lays the groundwork. Expected
future work includes:

• ELFv2
• powerpc64le
• 32-bit support (running legacy Linux applications)

Sponsored by: Google Summer of Code
MFC after: 2 months

[emaste]

sys/compat/linux/linux_file.c

321–322

should this change apply to COMPAT_LINUX32 only, as with amd64?

sys/compat/linux/linux_ioctl.h

36

curious why this is needed now

354

curious about why these are excluded from __powerpc64__, perhaps a comment in the src

426

this should probably be a separate commit with a stated rationale

sys/conf/files.powerpc

380 ↗

(On Diff #131200)

undo this

sys/modules/linux64/Makefile

83–84

?

100–103

?

[jhibbits]

sys/compat/linux/linux_file.c

321–322

According to Linux's arch/powerpc/kernel/syscalls/syscall.tbl llseek is common. This really should be powerpc, not powerpc64, on the off-chance I add 32-bit compat.

sys/compat/linux/linux_ioctl.h

354

Curious. I didn't know, so just checked Linux. powerpc seems to be the *only* arch that uses lowercase 't'. I'll add a comment for it. This is also the case for TCSETS, etc., so all of these should be in one block, not sprinkled like this.

426

I'll have to rework this.

sys/conf/files.powerpc

380 ↗

(On Diff #131200)

That's an odd one, don't know how it snuck in here.

sys/modules/linux64/Makefile

83–84

My fault. My GSoC student (last year) had made some changes to this file that I didn't want to fully revert while I was doing the final merge. I forgot to remove this and below before submitting the review.

100–103

As above.

[imp]

I didn't have time for this whole thing.

sys/compat/linux/linux_ioctl.h

354

I know that PowerPC is the odd-man out for ABI issues, encoding, termios definitions, etc. All the others platforms we support on Linux use the common ABI stuff (by and large, there's interesting exceptions for i386 sometimes, but the common stuff often is the i386 stuff given Linux's development history).

When I did similar things for kboot, I created a per-arch .h file for this stuff as well as a common .h file that most things use. This ifdef soup is crazy and avoided that way.

sys/powerpc/linux/linux_genassym.c

2 ↗

(On Diff #131200)

This is bogus. Drop it. :)

sys/powerpc/linux/linux_locore.asm

3

The -FreeBSD SPDX identifier is obsolete and shouldn't be used at all.

sys/powerpc/linux/linux_machdep.c

33

Here and everywhere else: remove $FreeBSD$ and #include <sys/cdefs.h>

63

Should we return an error instead?

[jhibbits]

sys/compat/linux/linux_ioctl.h

426

It's even weirder than I thought. The powerpc ioctl list breaks the linuxulator ioctl registration code. There are two groups of terminal ioctls for powerpc: those that are formed via the macros, and those that match the rest (0x54xx). So in order to do this right, I'll need to break up the existing ioctl list into two lists, and register them separately.

[jhibbits]

sys/compat/linux/linux_ioctl.h

354

Interestingly, the powerpc ioctls here match the FreeBSD ioctls perfectly in many cases. Since our ABIs aren't changing... ever... I can just use our ioctl definitions for many of these in the powerpc case, and even use the _IOC() macros to generate them.

[jhibbits]

sys/compat/linux/linux_ioctl.h

36

Linux on powerpc defines LINUX_IOC_VOID as 0x20000000 (same as IOC_VOID on FreeBSD), all other archs FreeBSD runs on, Linux defines it as 0.

sys/powerpc/linux/linux_machdep.c

63

It's a trivial function, so implementing it.

[jhibbits]

Address feedback. Add new linux_ioctl_handler for powerpc-specific TTY ioctls.

[jhibbits]

Fix the build

[jhibbits]

Cleanup:

• Remove unnecessary code
  • linux_exec_setregs() is identical to exec_setregs(), so dedup. Could dedup even more, too.
• style(9) some bits

[jhibbits]

Ping? I think I addressed all feedback, but may have missed something.

[jhibbits]

Eliminate (most of) the ifdef soup in linux_ioctl.h by following @imp's suggestion.

[jhibbits]

Further updates. vdso maps correctly.

[imp]

Some more comments. I made it through only the first half of the review, and didn't review the system calls tables.

sys/amd64/linux/linux_termbits.h

4

Please consider the short form w/o the extra boiler plate, if you can, here and elsewhere.
It makes short files easier to deal with.

sys/compat/linux/linux_file.c

321–322

According to Linux's arch/powerpc/kernel/syscalls/syscall.tbl llseek is common. This really should be powerpc, not powerpc64, on the off-chance I add 32-bit compat.

Yes. I can confirm when I did the powerpc linuxboot stuff it was the odd-arch out.

sys/compat/linux/linux_ioctl.h

32

Uggg, why do we need this odd construct?

36

Linux on powerpc defines LINUX_IOC_VOID as 0x20000000 (same as IOC_VOID on FreeBSD), all other archs FreeBSD runs on, Linux defines it as 0.

I'd hoist what you just said here into the comment rather than being a bit cryptic.

592

Yea, I hated that powerpc was the odd-arch out for tty layer. More Linux ABI chasing vs BSD setting the ABI.

sys/powerpc/linux/linux.h

298

Just an aside... a Lot of this duplicates, in part, the work I did for the linux binaries for kboot. I can't help but wonder if we might profit from future work to converge the different sets of definitions. It didn't occur to me at the time I did the stand stuff to look here for that.

sys/powerpc/linux/linux_genassym.c

1 ↗

(On Diff #162215)

I wonder why this is needed at all... or is tor future work?

sys/powerpc/linux/linux_machdep.c

75

Is there a regnames you can use instead of these magic numbers?

sys/powerpc/linux/linux_sysvec.c

189

Picking this random TODO to comment:

There's a lot labeled as 'TODO'. I have two comments on that. (1) It's likely good to have some macro defines so that it whine / panics when the todo is hit. and (2) what's the minimum needed to make this viable? There's a lot missing, so knowing the 'acceptance test' or 'acceptance criteria' are good. Also, I ran out of time to do more than scan for obvious things somewhere in linxu_sigframe.h.

[emaste]

sys/compat/linprocfs/linprocfs.c

2709

Perhaps this should now be #if !defined(__i386__) instead?

[jhibbits]

sys/powerpc/linux/linux_genassym.c

1 ↗

(On Diff #162215)

Looks like this stub file was added just to minimize the Makefile diff.

sys/powerpc/linux/linux_machdep.c

75

Not currently. Naked numbers for registers are used everywhere in the powerpc tree. It's a good idea, but would result in a lot of churn throughout both src and libc if we were to do it completely, so we've just left it for as long as I've been a committer.

sys/powerpc/linux/linux_sysvec.c

189

Thanks for the feedback on this. It looks like several of the TODOs are ptrace related, and can likely be implemented without much trouble. This function I'll take a closer look at soon.

Regarding a noisy macro, maybe a LINUX_TODO macro for any Linuxulator TODOs, not just for the powerpc Linuxulator?

[emaste]

sys/powerpc/linux/linux_sysvec.c

189

Existing approach is generally a linux_msg listing the unimplemented functionality e.g.

sys/compat/linux/linux_mmap.c:          linux_msg(curthread, "unsupported madvise MADV_REMOVE");

[jhibbits]

Address all feedback. Since a lot of time has passed since, I also added more
features, primarily VMX/VSX and signal handling.

[jhibbits]

Add missing files linux_emul_md.{c,h}

[adrian]

sys/compat/linux/linux_ioctl.c

335

this stuff too?

sys/compat/linux/linux_ioctl.h

450

hm, in terms of "things we can pull out now", maybe pull this termio chunk out into the separate include file and just submit / land it as a separate diff?

sys/compat/linux/linux_util.h

183

maybe make this its own commit too?