bwlp/qemu.git/linux-user/i386, branch spice_video_codecs

linux-user: Add guest memory layout to exception dump

2022-10-25T07:20:40+00:00

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 Reviewed-by: Richard Henderson Message-Id: [lv: remove pc declaration and setting] Signed-off-by: Laurent Vivier

linux-user: i386/signal: support XSAVE/XRSTOR for signal frame fpstate

2022-10-11T08:27:35+00:00

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 Signed-off-by: Paolo Bonzini

linux-user: i386/signal: support FXSAVE fpstate on 32-bit emulation

2022-10-11T07:36:01+00:00

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 Signed-off-by: Paolo Bonzini

linux-user: i386/signal: move fpstate at the end of the 32-bit frames

2022-10-11T07:36:01+00:00

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 Signed-off-by: Paolo Bonzini

linux-user: Provide MADV_* definitions

2022-09-27T07:30:09+00:00

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 Reviewed-by: Richard Henderson Message-Id: <20220906000839.1672934-2-iii@linux.ibm.com> Signed-off-by: Laurent Vivier

linux-user: use 'max' instead of 'qemu32' / 'qemu64' by default

2022-09-23T12:04:17+00:00

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 Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Daniel P. Berrangé Message-Id: <20220923110413.70593-1-berrange@redhat.com> Signed-off-by: Laurent Vivier

misc: fix commonly doubled up words

2022-08-01T09:58:02+00:00

Signed-off-by: Daniel P. Berrangé Message-Id: <20220707163720.1421716-5-berrange@redhat.com> Reviewed-by: Peter Maydell Signed-off-by: Thomas Huth

Remove qemu-common.h include from most units

2022-04-06T12:31:55+00:00

Signed-off-by: Marc-André Lureau Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini

linux-user: Add missing "qemu/timer.h" include

2022-02-21T09:18:06+00:00

"qemu/timer.h" declares cpu_get_host_ticks(). Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Thomas Huth Reviewed-by: Richard Henderson Message-Id: <20220207082756.82600-9-f4bug@amsat.org> Signed-off-by: Thomas Huth

linux-user: Move generic TARGET_RLIMIT* definitions to generic/target_resource.h

2022-02-01T07:01:38+00:00

Signed-off-by: Serge Belyshev Message-Id: <87ee4ql3yk.fsf_-_@depni.sinp.msu.ru> Signed-off-by: Laurent Vivier