[RFC] um: an arm64 subarch for User Mode Linux

[contact]

Hi,

I have ARCH=um SUBARCH=arm64 working -- 33 patches on uml/next. Before
sending that many to the list I would like to know if it is wanted, and 
in
what shape.

  https://github.com/zalexdev/linux-um-arm64   (branch um-arm64)

Boots Alpine and Debian at 4K and 16K pages, SECCOMP and ptrace 
userspace,
loadable modules.

The part I want an opinion on is syscall interception on hosts without
PTRACE_SYSEMU, since 5.3 is a recent floor for arm64 and phones ship 
4.19.
There the guest syscall is cancelled by writing -1 to NT_ARM_SYSTEM_CALL 
at
a PTRACE_SYSCALL stop. That fails under a seccomp filter, though: arm64
reports the ptrace stop before running seccomp, so the filter sees the 
-1
and an Android app sandbox kills the tracee. So the third path 
substitutes
getppid(2) for the guest's call -- the call still does not run, but a
syscall does execute on the guest's behalf. Is that acceptable? nosysemu
and nocancel select the fallbacks on any host, so they are testable
without a 4.19 machine.

Modules reuse arch/arm64/kernel/module.c and module-plts.c instead of a
second copy, the way arch/x86/um does. That does mean pulling two files 
out
of arch/arm64.

Two changes are performance only. The stub handoff skips FUTEX_WAKE when
nobody is parked and spins against CNTVCT_EL0 before parking; anonymous
faults are batched onto the handoff that was happening anyway. 
Snapdragon
870, SECCOMP mode, medians of 7 interleaved rounds:

  syscall  9.841 -> 1.987 us
  openat  20.223 -> 4.501 us
  fault   24.592 -> 11.076 us

Known problems: no 32-bit compat, UP only, and "BUG: Bad rss-counter 
state
... type:MM_FILEPAGES val:1" once per exiting process under Debian but 
not
under Alpine on the same kernel. I have not found that one and would not
expect it merged as is.

About a third of the patches are not arm64 -- generic um/ fixes and two 
x86
ones, including a missing 32-bit stub_seccomp_save_state -- but they sit 
on
top of the subarch commit and do not apply alone. I can rebase them into 
a
separate series first if that is more useful.

I cannot commit to maintaining this long-term. Happy to respin or split 
it
however you want; say the word and I will send the series with
git send-email.

Thanks,
Oleksii