From 6fbef9426bac7184b5d5887589d8386e732865eb Mon Sep 17 00:00:00 2001 From: Richard Henderson Date: Sat, 14 Jan 2023 15:21:03 -1000 Subject: [PATCH 1/4] target/i386: Fix 32-bit AD[CO]X insns in 64-bit mode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Failure to truncate the inputs results in garbage for the carry-out. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1373 Signed-off-by: Richard Henderson Reviewed-by: Philippe Mathieu-Daudé Message-Id: <20230115012103.3131796-1-richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini --- target/i386/tcg/emit.c.inc | 2 + tests/tcg/x86_64/Makefile.target | 3 ++ tests/tcg/x86_64/adox.c | 69 ++++++++++++++++++++++++++++++++ 3 files changed, 74 insertions(+) create mode 100644 tests/tcg/x86_64/adox.c diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc index 0d7c6e80ae..e61ae9a2e9 100644 --- a/target/i386/tcg/emit.c.inc +++ b/target/i386/tcg/emit.c.inc @@ -1037,6 +1037,8 @@ static void gen_ADCOX(DisasContext *s, CPUX86State *env, MemOp ot, int cc_op) #ifdef TARGET_X86_64 case MO_32: /* If TL is 64-bit just do everything in 64-bit arithmetic. */ + tcg_gen_ext32u_tl(s->T0, s->T0); + tcg_gen_ext32u_tl(s->T1, s->T1); tcg_gen_add_i64(s->T0, s->T0, s->T1); tcg_gen_add_i64(s->T0, s->T0, carry_in); tcg_gen_shri_i64(carry_out, s->T0, 32); diff --git a/tests/tcg/x86_64/Makefile.target b/tests/tcg/x86_64/Makefile.target index 4eac78293f..e64aab1b81 100644 --- a/tests/tcg/x86_64/Makefile.target +++ b/tests/tcg/x86_64/Makefile.target @@ -12,11 +12,14 @@ ifeq ($(filter %-linux-user, $(TARGET)),$(TARGET)) X86_64_TESTS += vsyscall X86_64_TESTS += noexec X86_64_TESTS += cmpxchg +X86_64_TESTS += adox TESTS=$(MULTIARCH_TESTS) $(X86_64_TESTS) test-x86_64 else TESTS=$(MULTIARCH_TESTS) endif +adox: CFLAGS=-O2 + run-test-i386-ssse3: QEMU_OPTS += -cpu max run-plugin-test-i386-ssse3-%: QEMU_OPTS += -cpu max diff --git a/tests/tcg/x86_64/adox.c b/tests/tcg/x86_64/adox.c new file mode 100644 index 0000000000..36be644c8b --- /dev/null +++ b/tests/tcg/x86_64/adox.c @@ -0,0 +1,69 @@ +/* See if ADOX give expected results */ + +#include +#include +#include + +static uint64_t adoxq(bool *c_out, uint64_t a, uint64_t b, bool c) +{ + asm ("addl $0x7fffffff, %k1\n\t" + "adoxq %2, %0\n\t" + "seto %b1" + : "+r"(a), "=&r"(c) : "r"(b), "1"((int)c)); + *c_out = c; + return a; +} + +static uint64_t adoxl(bool *c_out, uint64_t a, uint64_t b, bool c) +{ + asm ("addl $0x7fffffff, %k1\n\t" + "adoxl %k2, %k0\n\t" + "seto %b1" + : "+r"(a), "=&r"(c) : "r"(b), "1"((int)c)); + *c_out = c; + return a; +} + +int main() +{ + uint64_t r; + bool c; + + r = adoxq(&c, 0, 0, 0); + assert(r == 0); + assert(c == 0); + + r = adoxl(&c, 0, 0, 0); + assert(r == 0); + assert(c == 0); + + r = adoxl(&c, 0x100000000, 0, 0); + assert(r == 0); + assert(c == 0); + + r = adoxq(&c, 0, 0, 1); + assert(r == 1); + assert(c == 0); + + r = adoxl(&c, 0, 0, 1); + assert(r == 1); + assert(c == 0); + + r = adoxq(&c, -1, -1, 0); + assert(r == -2); + assert(c == 1); + + r = adoxl(&c, -1, -1, 0); + assert(r == 0xfffffffe); + assert(c == 1); + + r = adoxq(&c, -1, -1, 1); + assert(r == -1); + assert(c == 1); + + r = adoxl(&c, -1, -1, 1); + assert(r == 0xffffffff); + assert(c == 1); + + return 0; +} From 3ada67a306904fe0eb3093aff9278439a0e093c8 Mon Sep 17 00:00:00 2001 From: Brad Smith Date: Sun, 18 Dec 2022 03:22:04 -0500 Subject: [PATCH 2/4] thread-posix: add support for setting threads name on OpenBSD MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Make use of pthread_set_name_np() to be able to set the threads name on OpenBSD. Signed-off-by: Brad Smith Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Message-Id: Signed-off-by: Paolo Bonzini --- meson.build | 12 ++++++++++++ util/qemu-thread-posix.c | 9 ++++++++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/meson.build b/meson.build index a76c855312..86e8ff9109 100644 --- a/meson.build +++ b/meson.build @@ -2133,6 +2133,18 @@ config_host_data.set('CONFIG_PTHREAD_SETNAME_NP_WO_TID', cc.links(gnu_source_pre pthread_create(&thread, 0, f, 0); return 0; }''', dependencies: threads)) +config_host_data.set('CONFIG_PTHREAD_SET_NAME_NP', cc.links(gnu_source_prefix + ''' + #include + #include + + static void *f(void *p) { return NULL; } + int main(void) + { + pthread_t thread; + pthread_create(&thread, 0, f, 0); + pthread_set_name_np(thread, "QEMU"); + return 0; + }''', dependencies: threads)) config_host_data.set('CONFIG_PTHREAD_CONDATTR_SETCLOCK', cc.links(gnu_source_prefix + ''' #include #include diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c index bae938c670..412caa45ef 100644 --- a/util/qemu-thread-posix.c +++ b/util/qemu-thread-posix.c @@ -18,6 +18,10 @@ #include "qemu/tsan.h" #include "qemu/bitmap.h" +#ifdef CONFIG_PTHREAD_SET_NAME_NP +#include +#endif + static bool name_threads; void qemu_thread_naming(bool enable) @@ -25,7 +29,8 @@ void qemu_thread_naming(bool enable) name_threads = enable; #if !defined CONFIG_PTHREAD_SETNAME_NP_W_TID && \ - !defined CONFIG_PTHREAD_SETNAME_NP_WO_TID + !defined CONFIG_PTHREAD_SETNAME_NP_WO_TID && \ + !defined CONFIG_PTHREAD_SET_NAME_NP /* This is a debugging option, not fatal */ if (enable) { fprintf(stderr, "qemu: thread naming not supported on this host\n"); @@ -480,6 +485,8 @@ static void *qemu_thread_start(void *args) pthread_setname_np(pthread_self(), qemu_thread_args->name); # elif defined(CONFIG_PTHREAD_SETNAME_NP_WO_TID) pthread_setname_np(qemu_thread_args->name); +# elif defined(CONFIG_PTHREAD_SET_NAME_NP) + pthread_set_name_np(pthread_self(), qemu_thread_args->name); # endif } QEMU_TSAN_ANNOTATE_THREAD_NAME(qemu_thread_args->name); From 8d0efbcfa0656bef76e95d40933b6243feca58c9 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Fri, 17 Feb 2023 13:09:56 +0100 Subject: [PATCH 3/4] docs: build-platforms: refine requirements on Python build dependencies MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Historically, the critical dependency for both building and running QEMU has been the distro packages. Because QEMU is written in C and C's package management has been tied to distros (at least if you do not want to bundle libraries with the binary, otherwise I suppose you could use something like conda or wrapdb), C dependencies of QEMU would target the version that is shipped in relatively old but still commonly used distros. For non-C libraries, however, the situation is different, as these languages have their own package management tool (cpan, pip, gem, npm, and so on). For some of these languages, the amount of dependencies for even a simple program can easily balloon to the point that many distros have given up on packaging non-C code. For this reason, it has become increasingly normal for developers to download dependencies into a self-contained local environment, instead of relying on distro packages. Fortunately, this affects QEMU only at build time, as qemu.git does not package non-C artifacts such as the qemu.qmp package; but still, as we make more use of Python, we experience a clash between a support policy that is written for the C world, and dependencies (both direct and indirect) that increasingly do not care for the distro versions and are quick at moving past Python runtime versions that are declared end-of-life. For example, Python 3.6 has been EOL'd since December 2021 and Meson 0.62 (released the following March) already dropped support for it. Yet, Python 3.6 is the default version of the Python runtime for RHEL/CentOS 8 and SLE 15, respectively the penultimate and the most recent version of two distros that QEMU would like to support. (It is also the version used by Ubuntu 18.04, but QEMU stopped supporting it in April 2022). There are good reasons to move forward with the deprecation of Python 3.6 in QEMU as well: completing the configure->meson switch (which requires Meson 0.63), and making the QAPI generator fully typed (which requires newer versions of not just mypy but also Python, due to PEP563). Fortunately, these long-term support distros do include newer versions of the Python runtime. However, these more recent runtimes only come with a very small subset of the Python packages that the distro includes. Because most dependencies are optional tests (avocado, mypy, flake8) and Meson is bundled with QEMU, the most noticeably missing package is Sphinx (and the readthedocs theme). There are four possibilities: * we change the support policy and stop supporting CentOS 8 and SLE 15; not a good idea since CentOS 8 is not an unreasonable distro for us to want to continue to support * we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being supported. This is a possibility---but we may want to revise the support policy anyway because SLE 16 has not even been released, so this would mean delaying those desirable reasons for perhaps three years; * we support Python 3.6 just for building documentation, i.e. we are careful not to use Python 3.7+ features in our Sphinx extensions but are free to use them elsewhere. Besides being more complicated to understand for developers, this can be quite limiting; parts of the QAPI generator run at sphinx-build time, which would exclude one of the areas which would benefit from a newer version of the runtime; * we only support Python 3.7+, which means CentOS 8 CI and users have to either install Sphinx from pip or disable documentation. This proposed update to the support policy chooses the last of these possibilities. It does by modifying three aspects of the support policy: * it introduces different support periods for *native* vs. *non-native* dependencies. Non-native dependencies are currently Python ones only, and for simplicity the policy only mentions Python; however, the concept generalizes to other languages with a well-known upstream package manager, that users of older distributions can fetch dependencies from; * it opens up the possibility of taking non-native dependencies from their own package index instead of using the version in the distribution. The wording right now is specific to dependencies that are only required at build time. In the future we may have to refine it if, for example, parts of QEMU will be written in Rust; in that case, crates would be handled in a similar way to submodules and vendored in the release tarballs. * it mentions specifically that optional build dependencies are excluded from the platform policy. Tools such as mypy don't affect the ability to build QEMU and move fast enough that distros cannot standardize on a single version of them (for example RHEL9 does not package them at all, nor does it run them at rpmbuild time). In other cases, such as cross compilers, we have alternatives. Right now, non-native dependencies have to be download manually by running "pip" before "configure". In the future, it will be desirable for configure to set up a virtual environment and download them in the same way that it populates git submodules (but, in this case, without vendoring them in the release tarballs). Just like with submodules, this would make things easier for people that can afford accessing the network in their build environment; the option to populate the build environment manually would remain for people whose build machines lack network access. The change to the support policy neither requires nor forbids this future change. [Thanks to Daniel P. Berrangé, Peter Maydell and others for discussions that were copied or summarized in the above commit message] Cc: Markus Armbruster Cc: Peter Maydell Cc: John Snow Cc: Kevin Wolf Reviewed-by: Daniel P. Berrangé Reviewed-by: Alex Bennée Signed-off-by: Paolo Bonzini --- docs/about/build-platforms.rst | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst index 1c1e7b9e11..20b97c3310 100644 --- a/docs/about/build-platforms.rst +++ b/docs/about/build-platforms.rst @@ -86,6 +86,38 @@ respective ports repository, while NetBSD will use the pkgsrc repository. For macOS, `Homebrew`_ will be used, although `MacPorts`_ is expected to carry similar versions. +Some build dependencies may follow less conservative rules: + +Python runtime + Distributions with long-term support often provide multiple versions + of the Python runtime. While QEMU will initially aim to support the + distribution's default runtime, it may later increase its minimum version + to any newer python that is available as an option from the vendor. + In this case, it will be necessary to use the ``--python`` command line + option of the ``configure`` script to point QEMU to a supported + version of the Python runtime. + + As of QEMU |version|, the minimum supported version of Python is 3.6. + +Python build dependencies + Some of QEMU's build dependencies are written in Python. Usually these + are only packaged by distributions for the default Python runtime. + If QEMU bumps its minimum Python version and a non-default runtime is + required, it may be necessary to fetch python modules from the Python + Package Index (PyPI) via ``pip``, in order to build QEMU. + +Optional build dependencies + Build components whose absence does not affect the ability to build + QEMU may not be available in distros, or may be too old for QEMU's + requirements. Many of these, such as the Avocado testing framework + or various linters, are written in Python and therefore can also + be installed using ``pip``. Cross compilers are another example + of optional build-time dependency; in this case it is possible to + download them from repositories such as EPEL, to use container-based + cross compilation using ``docker`` or ``podman``, or to use pre-built + binaries distributed with QEMU. + + Windows ------- From 49be78ca02a687ea00ad7534254217b479a4e92d Mon Sep 17 00:00:00 2001 From: TaiseiIto Date: Mon, 19 Dec 2022 13:04:12 +0900 Subject: [PATCH 4/4] target/i386/gdbstub: Fix a bug about order of FPU stack in 'g' packets. Before this commit, when GDB attached an OS working on QEMU, order of FPU stack registers printed by GDB command 'info float' was wrong. There was a bug causing the problem in 'g' packets sent by QEMU to GDB. The packets have values of registers of machine emulated by QEMU containing FPU stack registers. There are 2 ways to specify a x87 FPU stack register. The first is specifying by absolute indexed register names (R0, ..., R7). The second is specifying by stack top relative indexed register names (ST0, ..., ST7). Values of the FPU stack registers should be located in 'g' packet and be ordered by the relative index. But QEMU had located these registers ordered by the absolute index. After this commit, when QEMU reads registers to make a 'g' packet, QEMU specifies FPU stack registers by the relative index. Then, the registers are ordered correctly in the packet. As a result, GDB, the packet receiver, can print FPU stack registers in the correct order. Signed-off-by: TaiseiIto Reviewed-by: Richard Henderson Message-Id: Signed-off-by: Paolo Bonzini --- target/i386/gdbstub.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c index c3a2cf6f28..786971284a 100644 --- a/target/i386/gdbstub.c +++ b/target/i386/gdbstub.c @@ -121,7 +121,9 @@ int x86_cpu_gdb_read_register(CPUState *cs, GByteArray *mem_buf, int n) return gdb_get_reg32(mem_buf, env->regs[gpr_map32[n]]); } } else if (n >= IDX_FP_REGS && n < IDX_FP_REGS + 8) { - floatx80 *fp = (floatx80 *) &env->fpregs[n - IDX_FP_REGS]; + int st_index = n - IDX_FP_REGS; + int r_index = (st_index + env->fpstt) % 8; + floatx80 *fp = &env->fpregs[r_index].d; int len = gdb_get_reg64(mem_buf, cpu_to_le64(fp->low)); len += gdb_get_reg16(mem_buf, cpu_to_le16(fp->high)); return len;