This command is needed to be able to boot systemd in a container.
$ sudo systemd-nspawn -D /chroot/armhf/sid/ -b
Spawning container sid on /chroot/armhf/sid.
Press ^] three times within 1s to kill container.
systemd 245.6-2 running in system mode.
Detected virtualization systemd-nspawn.
Detected architecture arm.
Welcome to Debian GNU/Linux bullseye/sid!
Set hostname to <virt-arm>.
Failed to enqueue loopback interface start request: Operation not supported
Caught <SEGV>, dumped core as pid 3.
Exiting PID 1...
Container sid failed with error code 255.
Only implement IFLA_PERM_ADDRESS to fix the following error:
Unknown host QEMU_IFLA type: 54
The couple of other ones, IFLA_PROP_LIST and IFLA_ALT_IFNAME, have
been introduced to be used with RTM_NEWLINKPROP, RTM_DELLINKPROP and
RTM_GETLINKPROP that are not implemented by QEMU.
linux-user/arm/signal.c: Drop TARGET_CONFIG_CPU_32
The Arm signal-handling code has some parts ifdeffed with a
TARGET_CONFIG_CPU_32, which is always defined. This is a leftover
from when this code's structure was based on the Linux kernel
signal handling code, where it was intended to support 26-bit
Arm CPUs. The kernel dropped its CONFIG_CPU_32 in kernel commit
4da8b8208eded0ba21e3 in 2009.
QEMU has never had 26-bit CPU support and is unlikely to ever
add it; we certainly aren't going to support 26-bit Linux
binaries via linux-user mode. The ifdef is just unhelpful
noise, so remove it entirely.
Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Richard Henderson <email address hidden>
Message-id: <email address hidden>
target/arm: Allow user-mode code to write CPSR.E via MSR
Using the MSR instruction to write to CPSR.E is deprecated, but it is
required to work from any mode including unprivileged code. We were
incorrectly forbidding usermode code from writing it because
CPSR_USER did not include the CPSR_E bit.
We use CPSR_USER in only three places:
* as the mask of what to allow userspace MSR to write to CPSR
* when deciding what bits a linux-user signal-return should be
able to write from the sigcontext structure
* in target_user_copy_regs() when we set up the initial
registers for the linux-user process
In the first two cases not being able to update CPSR.E is a bug, and
in the third case it doesn't matter because CPSR.E is always 0 there.
So we can fix both bugs by adding CPSR_E to CPSR_USER.
Because the cpsr_write() in restore_sigcontext() is now changing
a CPSR bit which is cached in hflags, we need to add an
arm_rebuild_hflags() call there; the callsite in
target_user_copy_regs() was already rebuilding hflags for other
reasons.
(The recommended way to change CPSR.E is to use the 'SETEND'
instruction, which we do correctly allow from usermode code.)
Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Richard Henderson <email address hidden>
Message-id: <email address hidden>
linux-user/arm: Fix identification of syscall numbers
Our code to identify syscall numbers has some issues:
* for Thumb mode, we never need the immediate value from the insn,
but we always read it anyway
* bad immediate values in the svc insn should cause a SIGILL, but we
were abort()ing instead (via "goto error")
We can fix both these things by refactoring the code that identifies
the syscall number to more closely follow the kernel COMPAT_OABI code:
* for Thumb it is always r7
* for Arm, if the immediate value is 0, then this is an EABI call
with the syscall number in r7
* otherwise, we XOR the immediate value with 0x900000
(ARM_SYSCALL_BASE for QEMU; __NR_OABI_SYSCALL_BASE in the kernel),
which converts valid syscall immediates into the desired value,
and puts all invalid immediates in the range 0x100000 or above
* then we can just let the existing "value too large, deliver
SIGILL" case handle invalid numbers, and drop the 'goto error'
Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Edgar E. Iglesias <email address hidden>
Message-id: <email address hidden>
The kernel has different handling for syscalls with invalid
numbers that are in the "arm-specific" range 0x9f0000 and up:
* 0x9f0000..0x9f07ff return -ENOSYS if not implemented
* other out of range syscalls cause a SIGILL
(see the kernel's arch/arm/kernel/traps.c:arm_syscall())
Implement this distinction. (Note that our code doesn't look
quite like the kernel's, because we have removed the
0x900000 prefix by this point, whereas the kernel retains
it in arm_syscall().)
Signed-off-by: Peter Maydell <email address hidden>
Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
Message-id: <email address hidden>
