* [PULL 1/4] target/i386: Fix 32-bit AD[CO]X insns in 64-bit mode
2023-02-22 14:40 [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Paolo Bonzini
@ 2023-02-22 14:41 ` Paolo Bonzini
2023-02-22 14:41 ` [PULL 2/4] thread-posix: add support for setting threads name on OpenBSD Paolo Bonzini
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2023-02-22 14:41 UTC (permalink / raw)
To: qemu-devel; +Cc: Richard Henderson, Philippe Mathieu-Daudé
From: Richard Henderson <richard.henderson@linaro.org>
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 <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230115012103.3131796-1-richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
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 0d7c6e80ae87..e61ae9a2e92d 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 4eac78293f2e..e64aab1b81c6 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 000000000000..36be644c8bc5
--- /dev/null
+++ b/tests/tcg/x86_64/adox.c
@@ -0,0 +1,69 @@
+/* See if ADOX give expected results */
+
+#include <assert.h>
+#include <stdint.h>
+#include <stdbool.h>
+
+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;
+}
--
2.39.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PULL 2/4] thread-posix: add support for setting threads name on OpenBSD
2023-02-22 14:40 [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Paolo Bonzini
2023-02-22 14:41 ` [PULL 1/4] target/i386: Fix 32-bit AD[CO]X insns in 64-bit mode Paolo Bonzini
@ 2023-02-22 14:41 ` Paolo Bonzini
2023-02-22 14:41 ` [PULL 3/4] docs: build-platforms: refine requirements on Python build dependencies Paolo Bonzini
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2023-02-22 14:41 UTC (permalink / raw)
To: qemu-devel; +Cc: Brad Smith, Philippe Mathieu-Daudé, Richard Henderson
From: Brad Smith <brad@comstyle.com>
Make use of pthread_set_name_np() to be able to set the threads name
on OpenBSD.
Signed-off-by: Brad Smith <brad@comstyle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <Y57NrCmPTVSXLWC4@humpty.home.comstyle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
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 a76c85531250..86e8ff91093f 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 <pthread.h>
+ #include <pthread_np.h>
+
+ 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 <pthread.h>
#include <time.h>
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
index bae938c67084..412caa45efb7 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 <pthread_np.h>
+#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);
--
2.39.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PULL 3/4] docs: build-platforms: refine requirements on Python build dependencies
2023-02-22 14:40 [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Paolo Bonzini
2023-02-22 14:41 ` [PULL 1/4] target/i386: Fix 32-bit AD[CO]X insns in 64-bit mode Paolo Bonzini
2023-02-22 14:41 ` [PULL 2/4] thread-posix: add support for setting threads name on OpenBSD Paolo Bonzini
@ 2023-02-22 14:41 ` Paolo Bonzini
2023-02-22 14:41 ` [PULL 4/4] target/i386/gdbstub: Fix a bug about order of FPU stack in 'g' packets Paolo Bonzini
2023-02-24 15:07 ` [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Peter Maydell
4 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2023-02-22 14:41 UTC (permalink / raw)
To: qemu-devel
Cc: Markus Armbruster, Peter Maydell, John Snow, Kevin Wolf,
Daniel P . Berrangé, Alex Bennée
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 <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
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 1c1e7b9e11c3..20b97c33109d 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
-------
--
2.39.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PULL 4/4] target/i386/gdbstub: Fix a bug about order of FPU stack in 'g' packets.
2023-02-22 14:40 [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Paolo Bonzini
` (2 preceding siblings ...)
2023-02-22 14:41 ` [PULL 3/4] docs: build-platforms: refine requirements on Python build dependencies Paolo Bonzini
@ 2023-02-22 14:41 ` Paolo Bonzini
2023-02-24 15:07 ` [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Peter Maydell
4 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2023-02-22 14:41 UTC (permalink / raw)
To: qemu-devel; +Cc: TaiseiIto, Richard Henderson
From: TaiseiIto <taisei1212@outlook.jp>
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 <taisei1212@outlook.jp>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <TY0PR0101MB4285923FBE9AD97CE832D95BA4E59@TY0PR0101MB4285.apcprd01.prod.exchangelabs.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
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 c3a2cf6f2825..786971284ae7 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;
--
2.39.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PULL 0/4] Misc + target/i386 pull request for 2023-02-22
2023-02-22 14:40 [PULL 0/4] Misc + target/i386 pull request for 2023-02-22 Paolo Bonzini
` (3 preceding siblings ...)
2023-02-22 14:41 ` [PULL 4/4] target/i386/gdbstub: Fix a bug about order of FPU stack in 'g' packets Paolo Bonzini
@ 2023-02-24 15:07 ` Peter Maydell
4 siblings, 0 replies; 6+ messages in thread
From: Peter Maydell @ 2023-02-24 15:07 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
On Wed, 22 Feb 2023 at 14:41, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> The following changes since commit 003ba52a8b327180e284630b289c6ece5a3e08b9:
>
> Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2023-02-16 11:16:39 +0000)
>
> are available in the Git repository at:
>
> https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 49be78ca02a687ea00ad7534254217b479a4e92d:
>
> target/i386/gdbstub: Fix a bug about order of FPU stack in 'g' packets. (2023-02-21 13:46:49 +0100)
>
> ----------------------------------------------------------------
> * x86 bugfixes
> * OpenBSD support for naming threads
> * Refined Python support policy
>
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/8.0
for any user-visible changes.
-- PMM
^ permalink raw reply [flat|nested] 6+ messages in thread