Both parameters have a different value on the parisc platform, so first
translate the target value into a host value for usage in the native
madvise() syscall.
Those parameters are often used by security sensitive applications (e.g.
tor browser, boringssl, ...) which expect the call to return a proper
return code on failure, so return -EINVAL if qemu fails to forward the
syscall to the host OS.
While touching this code, enhance the comments about MADV_DONTNEED.
Tested with testcase of tor browser when running hppa-linux guest on
x86-64 host.
Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <Y5iwTaydU7i66K/i@p100>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Make the strace look nicer for those two syscalls.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <Y9QxskymWJjrKQmT@p100>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The hppa architectures provides an own output for the emulated
/proc/cpuinfo file.
Some userspace applications count (even if that's not the recommended
way) the number of lines which start with "processor:" and assume that
this number then reflects the number of online CPUs. Since those 3
architectures don't provide any such line, applications may assume "0"
CPUs. One such issue can be seen in debian bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024653
Avoid such issues by adding a "processor:" line for each of the online
CPUs.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <Y9QvyRSq1I1k5/JW@p100>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Add translation for the host error return code of:
getsockopt(19, SOL_SOCKET, SO_ERROR, [ECONNREFUSED], [4]) = 0
This fixes the testsuite of the cockpit debian package with a
hppa-linux guest on a x86-64 host.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <Y9QzNzXg0hrzHQeo@p100>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This makes target_flat.h behave like every other target_xxx.h header.
It also makes it actually work -- while the current header says adding
a header to the target subdir overrides the common one, it doesn't.
This is for two reasons:
* meson.build adds -Ilinux-user before -Ilinux-user/$arch
* the compiler search path for "target_flat.h" looks in the same dir
as the source file before searching -I paths.
This can be seen with the xtensa port -- the subdir settings aren't
used which breaks stack setup.
Move it to the generic/ subdir and add include stubs like every
other target_xxx.h header is handled.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230129004625.11228-1-vapier@gentoo.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This reverts commit 3cd3df2a95.
glibc has fixed (in 2.36.9000-40-g774058d729) the problem
that caused a clash when both sys/mount.h annd linux/mount.h
are included, and backported this to the 2.36 stable release
too:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
It is saner for QEMU to remove the workaround it applied for
glibc 2.36 and expect distros to ship the 2.36 maint release
with the fix. This avoids needing to add a further workaround
to QEMU to deal with the fact that linux/brtfs.h now also pulls
in linux/mount.h via linux/fs.h since Linux 6.1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20230110174901.2580297-3-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This reverts commit c5495f4ecb.
glibc has fixed (in 2.36.9000-40-g774058d729) the problem
that caused a clash when both sys/mount.h annd linux/mount.h
are included, and backported this to the 2.36 stable release
too:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3E
It is saner for QEMU to remove the workaround it applied for
glibc 2.36 and expect distros to ship the 2.36 maint release
with the fix. This avoids needing to add a further workaround
to QEMU to deal with the fact that linux/brtfs.h now also pulls
in linux/mount.h via linux/fs.h since Linux 6.1
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20230110174901.2580297-2-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Currently, qemu strace only prints four protocol contants. This patch
adds others listed in "linux/netlink.h".
Signed-off-by: Letu Ren <fantasquex@gmail.com>
Message-Id: <20230101141105.12024-1-fantasquex@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This reinstates commit 52f0c16076:
While forcing the CPU to unrealize by hand does trigger the clean-up
code we never fully free resources because refcount never reaches
zero. This is because QOM automatically added objects without an
explicit parent to /unattached/, incrementing the refcount.
Instead of manually triggering unrealization just unparent the object
and let the device machinery deal with that for us.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/866
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220811151413.3350684-2-alex.bennee@linaro.org>
The original patch tickled a problem in target/arm, and was reverted.
But that problem is fixed as of commit 3b07a936d3.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230124201019.3935934-1-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
execve() is a particular case of execveat(). In order
to add do_execveat(), first factor do_execve() out.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Message-Id: <20221104081015.706009-1-sir@cmpwn.com>
[PMD: Split of bigger patch, filled description, fixed style]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20221104173632.1052-5-philmd@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In order to add print_execveat() which re-use common code from
print_execve(), extract print_execve_argv() from it.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
Message-Id: <20221104081015.706009-1-sir@cmpwn.com>
[PMD: Split of bigger patch, filled description, fixed style]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20221104173632.1052-3-philmd@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This commit re-enables ppc32 as a linux-user host,
as existance of the directory is noted by configure.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1097
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20220729172141.1789105-3-richard.henderson@linaro.org>
Add ability to dump /tmp/perf-<pid>.map and jit-<pid>.dump.
The first one allows the perf tool to map samples to each individual
translation block. The second one adds the ability to resolve symbol
names, line numbers and inspect JITed code.
Example of use:
perf record qemu-x86_64 -perfmap ./a.out
perf report
or
perf record -k 1 qemu-x86_64 -jitdump ./a.out
DEBUGINFOD_URLS= perf inject -j -i perf.data -o perf.data.jitted
perf report -i perf.data.jitted
Co-developed-by: Vanderson M. do Rosario <vandersonmr2@gmail.com>
Co-developed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230112152013.125680-4-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Add libdw-based functions for loading and querying debuginfo. Load
debuginfo from the system and the linux-user loaders.
This is useful for the upcoming perf support, which can then put
human-readable guest symbols instead of raw guest PCs into perfmap and
jitdump files.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230112152013.125680-3-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
When exiting due to an exit() syscall, qemu-user calls
preexit_cleanup(), but this is currently not the case when exiting due
to a signal. This leads to various buffers not being flushed (e.g.,
for gprof, for gcov, and for the upcoming perf support).
Add the missing call.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230112152013.125680-2-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This patch fixes the issue originally reported in
this thread:
https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg01102.html
The root cause of the issue is a bug in the hexagon specific
logic for saving & restoring context during signal delivery.
The CPU state has two different representations for the
predicate registers. The current logic saves & restores only
the aliased HEX_REG_P3_O register, which is part of env->gpr[]
field in the CPU state, but not the individual byte-level
predicate registers (pO, p1, p2, p3) backed by env->pred[].
Since all predicated instructions refer only to the
indiviual registers, switching to and back from a signal handler
can clobber these registers if the signal handler writes to them
causing the normal application code to behave unpredictably when
context is restored.
In the reported issue with the 'signals' test, since the updated
hexagon toolchain had built musl with -O2, the functions called
from non_trivial_free were inlined. This meant that the code
emitted reused predicate P0 computed in the entry translation
block of the function non_trivial_free in one of the child TB
as part of an assertion. Since P0 is clobbered by the signal
handler in the signals test, the assertion in non_trivial_free
fails incorectly. Since musl for hexagon implements the 'abort'
function by deliberately writing to memory via null pointer,
this causes the test to fail with segmentation fault.
This patch modifies the signal context save & restore logic
to include the individual p0, p1, p2, p3 and excludes the
32b p3_0 register since its value is derived from the former
registers. It also adds a new test case that reliabily
reproduces the issue for all four predicate registers.
Buglink: https://github.com/quic/toolchain_for_hexagon/issues/6
Signed-off-by: Mukilan Thiyagarajan <quic_mthiyaga@quicinc.com>
Signed-off-by: Taylor Simpson <tsimpson@quicinc.com>
Reviewed-by: Taylor Simpson <tsimpson@quicinc.com>
Message-Id: <20221229092006.10709-2-quic_mthiyaga@quicinc.com>
It's possible that a message contains both normal payload and ancillary
data in the same message, and even if no ancillary data is available
this information should be passed to the target, otherwise the target
cmsghdr will be left uninitialized and the target is going to access
uninitialized memory if it expects cmsg.
Always call the function that translate cmsg when recvmsg, because that
function should be empty-cmsg-safe (it creates an empty cmsg in the
target).
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20221028081220.1604244-1-uwu@icenowy.me>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The glibc on the hppa platform uses the "iitlbp %r0,(%sr0, %r0)"
assembler instruction as ABORT_INSTRUCTION.
If this (in userspace context) illegal assembler statement is found,
dump the registers and report the failure to userspace the same way as
the Linux kernel on physical hardware.
For other illegal instructions report TARGET_ILL_ILLOPC instead of
TARGET_ILL_ILLOPN as si_code.
Additionally add the missing EXCP_BREAK exception handler which occurs
when the "break x,y" assembler instruction is executed and report
EXCP_ASSIST traps.
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <Y1osHVsylkuZNUnY@p100>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
When PAGE_RESET is set, we are replacing pages with new
content, which means that we need to invalidate existing
cached data, such as TranslationBlocks. Perform the
reset invalidate while we're doing other invalidates,
which allows us to remove the separate invalidates from
the user-only mmap/munmap/mprotect routines.
In addition, restrict invalidation to PAGE_EXEC pages.
Since cdf7130851, we have validated PAGE_EXEC is present
before translation, which means we can assume that if the
bit is not present, there are no translations to invalidate.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
When the emulation stops with a hard exception it's very useful for
debugging purposes to dump the current guest memory layout (for an
example see /proc/self/maps) beside the CPU registers.
The open_self_maps() function provides such a memory dump, but since
it's located in the syscall.c file, various changes (add #includes, make
this function externally visible, ...) are needed to be able to call it
from the existing EXCP_DUMP() macro.
This patch takes another approach by re-defining EXCP_DUMP() to call
target_exception_dump(), which is in syscall.c, consolidates the log
print functions and allows to add the call to dump the memory layout.
Beside a reduced code footprint, this approach keeps the changes across
the various callers minimal, and keeps EXCP_DUMP() highlighted as
important macro/function.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <Y1bzAWbw07WBKPxw@p100>
[lv: remove pc declaration and setting]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations that don't fallback to faccessat
so normal access checks are failing without the emulation in place.
Tested by successfully emerging several packages within a Gentoo loong
stage3 chroot, emulated on amd64 with help of static qemu-loongarch64.
Reported-by: Andreas K. Hüttel <dilfridge@gentoo.org>
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Message-Id: <20221009060813.2289077-1-xen0n@gentoo.org>
[lv: removing defined(__NR_faccessat2) in syscall.c,
adding defined(TARGET_NR_faccessat2) on print_faccessat()]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
These ioctls have been defined in linux/fs.h for a long time
* BLKGETSIZE64 - <2.6.12 (linux.git epoch)
* BLKDISCARD - 2.6.28 (d30a2605be9d5132d95944916e8f578fcfe4f976)
* BLKIOMIN - 2.6.32 (ac481c20ef8f6c6f2be75d581863f40c43874ef7)
* BLKIOOPT - 2.6.32 (ac481c20ef8f6c6f2be75d581863f40c43874ef7)
* BLKALIGNOFF - 2.6.32 (ac481c20ef8f6c6f2be75d581863f40c43874ef7)
* BLKPBSZGET - 2.6.32 (ac481c20ef8f6c6f2be75d581863f40c43874ef7)
* BLKDISCARDZEROES - 2.6.32 (98262f2762f0067375f83824d81ea929e37e6bfe)
* BLKSECDISCARD - 2.6.36 (8d57a98ccd0b4489003473979da8f5a1363ba7a3)
* BLKROTATIONAL - 3.2 (ef00f59c95fe6e002e7c6e3663cdea65e253f4cc)
* BLKZEROOUT - 3.6 (66ba32dc167202c3cf8c86806581a9393ec7f488)
* FIBMAP - <2.6.12 (linux.git epoch)
* FIGETBSZ - <2.6.12 (linux.git epoch)
and when building with latest glibc, we'll see compat definitions
in syscall.c anyway thanks to the previous patch. Thus we can
assume they always exist and remove the conditional checks.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20221004093206.652431-3-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
GLibc changes prevent us from including linux/fs.h anymore,
and we previously adjusted to this in
commit 3cd3df2a95
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Tue Aug 2 12:41:34 2022 -0400
linux-user: fix compat with glibc >= 2.36 sys/mount.h
That change required adding compat ioctl definitions on the
QEMU side for any ioctls that we would otherwise obtain
from linux/fs.h. This commit adds more that were initially
missed, due to their usage being conditionalized in QEMU.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20221004093206.652431-2-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
AT_EXECFD gives access to the binary file even if
it is not readable (only executable).
Moreover it can be opened with flags and mode that are not the ones
provided by do_openat() caller.
And it is not available because loader_exec() has closed it.
To avoid that, use only safe_openat() with the exec_path.
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220927124357.688536-3-laurent@vivier.eu>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
If path is /proc/self/exe, use the executable path
provided by exec_path.
Don't use execfd as it is closed by loader_exec() and otherwise
will survive to the exec() syscall and be usable child process.
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220927124357.688536-2-laurent@vivier.eu>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In commit 80f0fe3a85 ("linux-user: Fix syscall parameter handling for
MIPS n32") the ABI problem regarding offset64 on MIPS n32 was fixed,
but still some cases remain where the n32 is incorrectly treated as any
other 32-bit ABI that passes 64-bit arguments in pairs of GPRs. Fix by
excluding TARGET_ABI_MIPSN32 from various TARGET_ABI_BITS == 32 checks.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/1238
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Andreas K. Hüttel <dilfridge@gentoo.org>
Cc: Joshua Kinard <kumba@gentoo.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Tested-by: Andreas K. Huettel <dilfridge@gentoo.org>
Message-Id: <20221006085500.290341-1-xen0n@gentoo.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Previously the 32-bit version was incorrectly chosen, leading to funny
but incorrect output from e.g. df(1). Simply select the version
corresponding to the 64-bit asm-generic definition.
For reference, this program should produce the same output no matter
natively compiled or not, for loongarch64 or not:
```c
#include <stdio.h>
#include <sys/statfs.h>
int main(int argc, const char *argv[])
{
struct statfs b;
if (statfs(argv[0], &b))
return 1;
printf("f_type = 0x%lx\n", b.f_type);
printf("f_bsize = %ld\n", b.f_bsize);
printf("f_blocks = %ld\n", b.f_blocks);
printf("f_bfree = %ld\n", b.f_bfree);
printf("f_bavail = %ld\n", b.f_bavail);
return 0;
}
// Example output on my amd64 box, with the test binary residing on a
// btrfs partition.
// Native and emulated output after the fix:
//
// f_type = 0x9123683e
// f_bsize = 4096
// f_blocks = 268435456
// f_bfree = 168406890
// f_bavail = 168355058
// Output before the fix, note the messed layout:
//
// f_type = 0x10009123683e
// f_bsize = 723302085239504896
// f_blocks = 168355058
// f_bfree = 2250817541779750912
// f_bavail = 1099229433104
```
Fixes: 1f63019632 ("linux-user: Add LoongArch syscall support")
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Cc: Song Gao <gaosong@loongson.cn>
Cc: Xiaojuan Yang <yangxiaojuan@loongson.cn>
Cc: Andreas K. Hüttel <dilfridge@gentoo.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Andreas K. Huettel <dilfridge@gentoo.org>
Message-Id: <20221006100710.427252-1-xen0n@gentoo.org>
Signed-off-by: Song Gao <gaosong@loongson.cn>
Add support for saving/restoring extended save states when signals
are delivered. This allows using AVX, MPX or PKRU registers in
signal handlers.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Linux can use FXSAVE to save/restore XMM registers even on 32-bit
systems. This requires some care in order to keep the FXSAVE area
aligned to 16 bytes; for this reason, get_sigframe is changed to
pass the offset into the FXSAVE area rather than the full frame
size.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Recent versions of Linux moved the 32-bit fpstate towards the end of the
frame, so that the variable-sized xsave data does not overwrite the
(ABI-defined) extramask[] field. Follow suit in QEMU.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Special care needs to be taken in ensuring locks are in a consistent
state across fork events. Add helpers so the plugin system can ensure
that.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/358
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20221004115221.2174499-1-alex.bennee@linaro.org>
The value previously chosen overlaps GUSA_MASK.
Rename all DELAY_SLOT_* and GUSA_* defines to emphasize
that they are included in TB_FLAGs. Add aliases for the
FPSCR and SR bits that are included in TB_FLAGS, so that
we don't accidentally reassign those bits.
Fixes: 4da06fb306 ("target/sh4: Implement prctl_unalign_sigbus")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/856
Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Do not allow syscall arguments to be interleaved between threads.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220829021006.67305-8-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Use a table for the names; print unknown values in hex,
since the value contains flags.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220829021006.67305-7-richard.henderson@linaro.org>
[lv: update print_futex() according to
"linux-user: Show timespec on strace for futex()"]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The val argument to FUTEX_FD is a signal number. Convert to match
the host, as it will be converted back when the signal is delivered.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220829021006.67305-5-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Leave only the argument adjustments within the shift,
and sink the actual syscall to the end. Sink the
timespec conversion as well, as there will be more users.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220829021006.67305-3-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Pass a boolean to select between time32 and time64.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220829021006.67305-2-richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Match most appropriate base platform string based on insn_flags.
Logic is aligned with aligned with set_isa() from
arch/mips/kernel/cpu-probe.c in Linux kernel.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220803103009.95972-3-jiaxun.yang@flygoat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
AT_BASE_PLATFORM is a elf auxiliary vector pointing to a string
to pass some architecture information.
See getauxval(3) man-page.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220803103009.95972-2-jiaxun.yang@flygoat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Linux kernel does this in fpregs_store() and fpregs_load(), so
qemu-user should do this as well.
Found by running valgrind's none/tests/s390x/test_sig.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220817123902.585623-1-iii@linux.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
For handling guest POSIX timers, we currently use an array
g_posix_timers[], whose entries are a host timer_t value, or 0 for
"this slot is unused". When the guest calls the timer_create syscall
we look through the array for a slot containing 0, and use that for
the new timer.
This scheme assumes that host timer_t values can never be zero. This
is unfortunately not a valid assumption -- for some host libc
versions, timer_t values are simply indexes starting at 0. When
using this kind of host libc, the effect is that the first and second
timers end up sharing a slot, and so when the guest tries to operate
on the first timer it changes the second timer instead.
Rework the timer allocation code, so that:
* the 'slot in use' indication uses a separate array from the
host timer_t array
* we grab the free slot atomically, to avoid races when multiple
threads call timer_create simultaneously
* releasing an allocated slot is abstracted out into a new
free_host_timer_slot() function called in the correct places
This fixes:
* problems on hosts where timer_t 0 is valid
* the FIXME in next_free_host_timer() about locking
* bugs in the error paths in timer_create where we forgot to release
the slot we grabbed, or forgot to free the host timer
Reported-by: Jon Alduan <jon.alduan@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20220725110035.1273441-1-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Fixes: 66fb9763af ("basic signal handling")
Fixes: cf8b8bfc50 ("linux-user: add support for rt_tgsigqueueinfo() system call")
Signed-off-by: fanwenjie <fanwj@mail.ustc.edu.cn>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
We don't emulate a preemptive kernel on this level, and the hppa architecture
doesn't allow context switches on the gateway page. So we always have to return
to sc_iaoq[] and not to gr[31].
This fixes the remaining random segfaults which still occured.
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <20220924114501.21767-8-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The hppa platform uses an upwards-growing stack and required in Linux
kernels < 5.18 an executable stack for signal processing. For that some
executables and libraries are marked to have an executable stack, for
which glibc uses the mprotect() syscall to mark the stack like this:
mprotect(xfa000000,4096,PROT_EXEC|PROT_READ|PROT_WRITE|PROT_GROWSUP).
Currently qemu will return -TARGET_EINVAL for this syscall because of the
checks in validate_prot_to_pageflags(), which doesn't allow the
PROT_GROWSUP or PROT_GROWSDOWN flags and thus triggers this error in the
guest:
error while loading shared libraries: libc.so.6: cannot enable executable stack as shared object requires: Invalid argument
Allow mprotect() to handle both flags and thus fix the guest.
The glibc tst-execstack testcase can be used to reproduce the issue.
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <20220924114501.21767-7-deller@gmx.de>
[lvivier: s/elif TARGET_HPPA/elif defined(TARGET_HPPA)/]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The hppa target requires a much bigger stack than many other targets,
and the Linux kernel allocates 80 MB by default for it.
This patch increases the guest stack for hppa to 80MB, and prevents
that this default stack size gets reduced by a lower stack limit on the
host.
Since the stack grows upwards on hppa, the stack_limit value marks the
upper boundary of the stack. Fix the output of /proc/self/maps (in the
guest) to show the [stack] marker on the correct memory area.
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <20220924114501.21767-6-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The stack-overflow check when building the "grep" debian package fails
on the debian hppa target. Reason is, that the guard page at the top
of the stack (which is added by qemu) prevents the fault handler in the
grep program to properly detect the stack overflow.
The Linux kernel on a physical machine doesn't install a guard page
either, so drop it and as such fix the build of "grep".
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <20220924114501.21767-5-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In Linux kernel v5.18 the vDSO for signal trampoline was added.
This code mimiks the bare minimum of this vDSO and thus avoids that the
parisc emulation needs executable stacks.
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <20220924114501.21767-4-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The xtensa platform has a value of 0x10 for PROT_SEM.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220924114501.21767-2-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This is a follow-up for commit 892a4f6a75 ("linux-user: Add partial
support for MADV_DONTNEED"), which added passthrough for anonymous
mappings. File mappings can be handled in a similar manner.
In order to do that, mark pages, for which mmap() was passed through,
with PAGE_PASSTHROUGH, and then allow madvise() passthrough for these
pages. Drop the explicit PAGE_ANON check, since anonymous mappings are
expected to have PAGE_PASSTHROUGH anyway.
Add PAGE_PASSTHROUGH to PAGE_STICKY in order to keep it on mprotect().
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220725125043.43048-1-iii@linux.ibm.com>
Message-Id: <20220906000839.1672934-5-iii@linux.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The default implementation has several problems: the first argument is
not displayed as a pointer, making it harder to grep; the third
argument is not symbolized; and there are several extra unused
arguments.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220906000839.1672934-4-iii@linux.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
MADV_DONTNEED has a different value on alpha, compared to all the other
architectures. Fix by using TARGET_MADV_DONTNEED instead of
MADV_DONTNEED.
Fixes: 892a4f6a75 ("linux-user: Add partial support for MADV_DONTNEED")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220906000839.1672934-3-iii@linux.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Provide MADV_* definitions using target_mman.h header, similar to what
kernel does. Most architectures use the same values, with the exception
of alpha and hppa.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220906000839.1672934-2-iii@linux.ibm.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
On the parisc architecture the stack grows upwards.
Move the TASK_UNMAPPED_BASE to high memory area as it's done by the
kernel on physical machines.
Signed-off-by: Helge Deller <deller@gmx.de>
Message-Id: <20220918194555.83535-9-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
If the mode parameter of chmod() is zero, this value isn't shown
when stracing a program:
chmod("filename",)
This patch fixes it up to show the zero-value as well:
chmod("filename",000)
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220918194555.83535-8-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Enhance the hppa linux-user cpu_loop() to show more debugging info
on hard errors.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220918194555.83535-6-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Enhance the EXCP_DUMP() macro to print out the failing program too.
During debugging it's sometimes hard to track down the actual failing
program if you are e.g. building a whole debian package.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220918194555.83535-5-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
I noticed those were missing when running the glib2.0 testsuite.
Add the syscalls including the strace output.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220918194555.83535-4-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Allow linux-user to strace the clock_gettime64() syscall.
This syscall is used a lot on 32-bit guest architectures which use newer
glibc versions.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220918194555.83535-3-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Some of the guest signal numbers are currently not converted to
their representative names in the strace output, e.g. SIGVTALRM.
This patch introduces a smart way to generate and keep in sync the
host-to-guest and guest-to-host signal conversion tables for usage in
the qemu signal and strace code. This ensures that any signals
will now show up in both tables.
There is no functional change in this patch - with the exception that yet
missing signal names now show up in the strace code too.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220918194555.83535-2-deller@gmx.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Exactly the same as f17f4989fa before was
for readlink. I suppose this was simply missed at the time.
Signed-off-by: Jameson Nash <vtjnash@gmail.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220808190727.875155-1-vtjnash@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The new noexec test fails on s390x with "unexpected SEGV". This test
overwrites code using libc's memcpy(), which uses VSTL instruction.
host_signal_write() does not recognize it, which causes SEGV to be
incorrectly forwarded to the test.
Add all vector instructions that write to memory to
host_signal_write().
Fixes: ab12c95d3f ("target/s390x: Make translator stop before the end of a page")
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20220920113907.334144-1-iii@linux.ibm.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
The 'qemu64' CPU model implements the least featureful x86_64 CPU that's
possible. Historically this hasn't been an issue since it was rare for
OS distros to build with a higher mandatory CPU baseline.
With RHEL-9, however, the entire distro is built for the x86_64-v2 ABI
baseline:
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
It is likely that other distros may take similar steps in the not too
distant future. For example, it has been suggested for Fedora on a
number of occasions.
This new baseline is not compatible with the qemu64 CPU model though.
While it is possible to pass a '-cpu xxx' flag to qemu-x86_64, the
usage of QEMU doesn't always allow for this. For example, the args
are typically controlled via binfmt rules that the user has no ability
to change. This impacts users who are trying to use podman on aarch64
platforms, to run containers with x86_64 content. There's no arg to
podman that can be used to change the qemu-x86_64 args, and a non-root
user of podman can not change binfmt rules without elevating privileges:
https://github.com/containers/podman/issues/15456#issuecomment-1228210973
Changing to the 'max' CPU model gives 'qemu-x86_64' maximum
compatibility with binaries it is likely to encounter in the wild,
and not likely to have a significant downside for existing usage.
Most other architectures already use an 'any' CPU model, which is
often mapped to 'max' (or similar) already, rather than the oldest
possible CPU model.
For the sake of consistency the 'i386' architecture is also changed
from using 'qemu32' to 'max'.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220923110413.70593-1-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Currently it's possible to execute pages that do not have PAGE_EXEC
if there is an existing translation block. Fix by invalidating TBs
that touch the affected pages.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20220817150506.592862-2-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Map the stack executable if required by default or on demand.
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We're about to start validating PAGE_EXEC, which means that we've
got to mark the vsyscall page executable. We had been special
casing this entirely within translate.
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We're about to start validating PAGE_EXEC, which means that we've
got to mark page zero executable. We had been special casing this
entirely within translate.
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
We're about to start validating PAGE_EXEC, which means
that we've got to mark the commpage executable. We had
been placing the commpage outside of reserved_va, which
was incorrect and lead to an abort.
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This reverts commit 52f0c16076.
This caused a regression in arm/aarch64.
We are hard-coding ARMCPRegInfo pointers into TranslationBlocks,
for calling into helper_{get,set}cp_reg{,64}. So we have a race
condition between whichever cpu thread translates the code first
(encoding the pointer), and that cpu thread exiting, so that the
next execution of the TB references a freed data structure.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
While forcing the CPU to unrealize by hand does trigger the clean-up
code we never fully free resources because refcount never reaches
zero. This is because QOM automatically added objects without an
explicit parent to /unattached/, incrementing the refcount.
Instead of manually triggering unrealization just unparent the object
and let the device machinery deal with that for us.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/866
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220811151413.3350684-2-alex.bennee@linaro.org>
aarch64 stores MTE tags in target_date, and they should be reset by
MADV_DONTNEED.
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220711220028.2467290-1-vitalybuka@google.com>
[lv: fix code style issues]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The latest glibc 2.36 has extended sys/mount.h so that it
defines the FSCONFIG_* enum constants. These are historically
defined in linux/mount.h, and thus if you include both headers
the compiler complains:
In file included from /usr/include/linux/fs.h:19,
from ../linux-user/syscall.c:98:
/usr/include/linux/mount.h:95:6: error: redeclaration of 'enum fsconfig_command'
95 | enum fsconfig_command {
| ^~~~~~~~~~~~~~~~
In file included from ../linux-user/syscall.c:31:
/usr/include/sys/mount.h:189:6: note: originally defined here
189 | enum fsconfig_command
| ^~~~~~~~~~~~~~~~
/usr/include/linux/mount.h:96:9: error: redeclaration of enumerator 'FSCONFIG_SET_FLAG'
96 | FSCONFIG_SET_FLAG = 0, /* Set parameter, supplying no value */
| ^~~~~~~~~~~~~~~~~
/usr/include/sys/mount.h:191:3: note: previous definition of 'FSCONFIG_SET_FLAG' with type 'enum fsconfig_command'
191 | FSCONFIG_SET_FLAG = 0, /* Set parameter, supplying no value */
| ^~~~~~~~~~~~~~~~~
...snip...
QEMU doesn't include linux/mount.h, but it does use
linux/fs.h and thus gets linux/mount.h indirectly.
glibc acknowledges this problem but does not appear to
be intending to fix it in the forseeable future, simply
documenting it as a known incompatibility with no
workaround:
https://sourceware.org/glibc/wiki/Release/2.36#Usage_of_.3Clinux.2Fmount.h.3E_and_.3Csys.2Fmount.h.3Ehttps://sourceware.org/glibc/wiki/Synchronizing_Headers
To address this requires either removing use of sys/mount.h
or linux/fs.h, despite QEMU needing declarations from
both.
This patch removes linux/fs.h, meaning we have to define
various FS_IOC constants that are now unavailable.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20220802164134.1851910-1-berrange@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
GDB LoongArch fpu use fcc register, update gdb_set_fpu()
and gdb_get_fpu() to match it.
Signed-off-by: Song Gao <gaosong@loongson.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220805033523.1416837-6-gaosong@loongson.cn>
For certain paths in /proc, the open syscall is intercepted and the
returned file descriptor points to a temporary file with emulated
contents.
If TMPDIR is not accessible or writable for the current user (for
example in a read-only mounted chroot or container) tools such as ps
from procps may fail unexpectedly. Trying to read one of these paths
such as /proc/self/stat would return an error such as ENOENT or EROFS.
To relax the requirement on a writable TMPDIR, use memfd_create()
instead to create an anonymous file and return its file descriptor.
Signed-off-by: Rainer Müller <raimue@codingfarm.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20220729154951.76268-1-raimue@codingfarm.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Follow the kernel's alignment, as we already noted.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1093
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20220729201942.30738-1-richard.henderson@linaro.org>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220707163720.1421716-5-berrange@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
