From: Simon Scherer <scherer.simon89@gmail.com>
To: qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, richard.henderson@linaro.org,
Simon Scherer <scherer.simon89@gmail.com>
Subject: [PATCH] target/i386: Do not switch to MMX mode for CVTPI2PS/CVTPI2PD with memory operand
Date: Tue, 1 Sep 2026 08:31:27 +0200 [thread overview]
Message-ID: <20260901063127.60866-1-scherer.simon89@gmail.com> (raw)
Per the Intel SDM, the CVTPI2PS and CVTPI2PD instructions
cause a transition from x87 FPU to MMX technology operation (the x87
top-of-stack pointer is set to 0 and the tag word is set to all
valid). CVTPI2PD's own description scopes this to the "xmm, mm"
operand form only, explicitly excluding "xmm, m64". But CVTPI2PS's
description states the transition unconditionally, without the same
operand-form distinction.
Testing on real hardware shows CVTPI2PS actually behaves identically
to CVTPI2PD despite the SDM wording: neither instruction performs the
state transition when the source is a memory operand, only when it is
an actual MMX register. This matches a similar Valgrind bug report
and fix, see https://bugs.kde.org/show_bug.cgi?id=357059.
gen_CVTPI2Px() currently calls gen_helper_enter_mmx() unconditionally,
regardless of the source operand's form. Only call it when the source
operand does not have an effective address, i.e. is a real MMX
register.
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4394
Signed-off-by: Simon Scherer <scherer.simon89@gmail.com>
---
target/i386/tcg/emit.c.inc | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc
index c83ab80940..72c08beb2a 100644
--- a/target/i386/tcg/emit.c.inc
+++ b/target/i386/tcg/emit.c.inc
@@ -1919,7 +1919,15 @@ static void gen_CRC32(DisasContext *s, X86DecodedInsn *decode)
static void gen_CVTPI2Px(DisasContext *s, X86DecodedInsn *decode)
{
- gen_helper_enter_mmx(tcg_env);
+ /*
+ * The x87->MMX transition only happens when the source is an MMX
+ * register, not for the memory-operand form. Confirmed on real
+ * hardware, contradicting the SDM's CVTPI2PS text. See
+ * https://bugs.kde.org/show_bug.cgi?id=357059.
+ */
+ if (!decode->op[2].has_ea) {
+ gen_helper_enter_mmx(tcg_env);
+ }
if (s->prefix & PREFIX_DATA) {
gen_helper_cvtpi2pd(tcg_env, OP_PTR0, OP_PTR2);
} else {
--
2.53.0
reply other threads:[~2026-09-01 6:32 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260901063127.60866-1-scherer.simon89@gmail.com \
--to=scherer.simon89@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.