#
0b30735d |
| 15-Feb-2024 |
Ziqiao Kong <ziqiaokong@gmail.com> |
target/i386: Generate an illegal opcode exception on cmp instructions with lock prefix
target/i386: As specified by Intel Manual Vol2 3-180, cmp instructions are not allowed to have lock prefix and
target/i386: Generate an illegal opcode exception on cmp instructions with lock prefix
target/i386: As specified by Intel Manual Vol2 3-180, cmp instructions are not allowed to have lock prefix and a `UD` should be raised. Without this patch, s1->T0 will be uninitialized and used in the case OP_CMPL.
Signed-off-by: Ziqiao Kong <ziqiaokong@gmail.com> Message-ID: <20240215095015.570748-2-ziqiaokong@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 99d0dcd7f102c07a510200d768cae65e5db25d23) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
#
c46f68bd |
| 17-Jan-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: pcrel: store low bits of physical address in data[0]
For PC-relative translation blocks, env->eip changes during the execution of a translation block, Therefore, QEMU must be able to re
target/i386: pcrel: store low bits of physical address in data[0]
For PC-relative translation blocks, env->eip changes during the execution of a translation block, Therefore, QEMU must be able to recover an instruction's PC just from the TranslationBlock struct and the instruction data with. Because a TB will not span two pages, QEMU stores all the low bits of EIP in the instruction data and replaces them in x86_restore_state_to_opc. Bits 12 and higher (which may vary between executions of a PCREL TB, since these only use the physical address in the hash key) are kept unmodified from env->eip. The assumption is that these bits of EIP, unlike bits 0-11, will not change as the translation block executes.
Unfortunately, this is incorrect when the CS base is not aligned to a page. Then the linear address of the instructions (i.e. the one with the CS base addred) indeed will never span two pages, but bits 12+ of EIP can actually change. For example, if CS base is 0x80262200 and EIP = 0x6FF4, the first instruction in the translation block will be at linear address 0x802691F4. Even a very small TB will cross to EIP = 0x7xxx, while the linear addresses will remain comfortably within a single page.
The fix is simply to use the low bits of the linear address for data[0], since those don't change. Then x86_restore_state_to_opc uses tb->cs_base to compute a temporary linear address (referring to some unknown instruction in the TB, but with the correct values of bits 12 and higher); the low bits are replaced with data[0], and EIP is obtained by subtracting again the CS base.
Huge thanks to Mark Cave-Ayland for the image and initial debugging, and to Gitlab user @kjliew for help with bisecting another occurrence of (hopefully!) the same bug.
It should be relatively easy to write a testcase that performs MMIO on an EIP with different bits 12+ than the first instruction of the translation block; any help is welcome.
Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11) Cc: qemu-stable@nongnu.org Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Richard Henderson <richard.henderson@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
#
652c34cb |
| 14-Jan-2024 |
guoguangyao <guoguangyao18@mails.ucas.ac.cn> |
target/i386: fix incorrect EIP in PC-relative translation blocks
The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case. Using s->pc in func gen_update_eip_next() solves the prob
target/i386: fix incorrect EIP in PC-relative translation blocks
The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case. Using s->pc in func gen_update_eip_next() solves the problem.
Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
#
6e8e580e |
| 01-Jan-2024 |
Richard Henderson <richard.henderson@linaro.org> |
target/i386: Do not re-compute new pc with CF_PCREL
With PCREL, we have a page-relative view of EIP, and an approximation of PC = EIP+CSBASE that is good enough to detect page crossings. If we try
target/i386: Do not re-compute new pc with CF_PCREL
With PCREL, we have a page-relative view of EIP, and an approximation of PC = EIP+CSBASE that is good enough to detect page crossings. If we try to recompute PC after masking EIP, we will mess up that approximation and write a corrupt value to EIP.
We already handled masking properly for PCREL, so the fix in b5e0d5d2 was only needed for the !PCREL path.
Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
#
b5e0d5d2 |
| 12-Dec-2023 |
Richard Henderson <richard.henderson@linaro.org> |
target/i386: Fix 32-bit wrapping of pc/eip computation
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap. Failure to do so results in incorrect memory exceptions to the guest. Before
target/i386: Fix 32-bit wrapping of pc/eip computation
In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap. Failure to do so results in incorrect memory exceptions to the guest. Before 732d548732ed, this was implicitly done via truncation to target_ulong but only in qemu-system-i386, not qemu-system-x86_64.
To fix this, we must add conditional zero-extensions. Since we have to test for 32 vs 64-bit anyway, note that cs_base is always zero in 64-bit mode.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org>
show more ...
|
#
23f3d586 |
| 19-Oct-2023 |
Richard Henderson <richard.henderson@linaro.org> |
target/i386: Use tcg_gen_ext_tl
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
|
#
46c684c8 |
| 24-Aug-2023 |
Richard Henderson <richard.henderson@linaro.org> |
target/i386: Use i128 for 128 and 256-bit loads and stores
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
|
#
24b34590 |
| 13-Oct-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: check intercept for XSETBV
Note that this intercept is special; it is checked before the #GP exception.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
1da389c5 |
| 04-Oct-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target/i386: Check for USER_ONLY definition instead of SOFTMMU one
Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one.
(target/ was cleaned
target/i386: Check for USER_ONLY definition instead of SOFTMMU one
Since we *might* have user emulation with softmmu, replace the system emulation check by !user emulation one.
(target/ was cleaned from invalid CONFIG_SOFTMMU uses at commit cab35c73be, but these files were merged few days after, thus missed the cleanup.)
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231004082239.27251-1-philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
b77af26e |
| 13-Sep-2023 |
Richard Henderson <richard.henderson@linaro.org> |
accel/tcg: Replace CPUState.env_ptr with cpu_env()
Reviewed-by: Anton Johansson <anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
|
#
ad75a51e |
| 13-Sep-2023 |
Richard Henderson <richard.henderson@linaro.org> |
tcg: Rename cpu_env to tcg_env
Allow the name 'cpu_env' to be used for something else.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@li
tcg: Rename cpu_env to tcg_env
Allow the name 'cpu_env' to be used for something else.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
#
19729aff |
| 25-Sep-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386/translate: avoid shadowed local variables
Just remove the declaration. There is nothing in the function after the switch statement, so it is safe to do.
Signed-off-by: Paolo Bonzini <p
target/i386/translate: avoid shadowed local variables
Just remove the declaration. There is nothing in the function after the switch statement, so it is safe to do.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
bad5cfcd |
| 14-Jul-2023 |
Michael Tokarev <mjt@tls.msk.ru> |
i386: spelling fixes
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
|
#
c1f27a0c |
| 29-Aug-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: raise FERR interrupt with iothread locked
Otherwise tcg_handle_interrupt() triggers an assertion failure:
#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2)
target/i386: raise FERR interrupt with iothread locked
Otherwise tcg_handle_interrupt() triggers an assertion failure:
#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83 #6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81 #7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555 #8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611 #9 0x00007fffa42bde14 in code_gen_buffer () #10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457
Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1808 Reported-by: NyanCatTW1 <https://gitlab.com/a0939712328> Co-developed-by: Richard Henderson <richard.henderson@linaro.org>' Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
e975434d |
| 29-Aug-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: raise FERR interrupt with iothread locked
Otherwise tcg_handle_interrupt() triggers an assertion failure:
#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2)
target/i386: raise FERR interrupt with iothread locked
Otherwise tcg_handle_interrupt() triggers an assertion failure:
#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83 #6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81 #7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555 #8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611 #9 0x00007fffa42bde14 in code_gen_buffer () #10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457
Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1808 Reported-by: NyanCatTW1 <https://gitlab.com/a0939712328> Co-developed-by: Richard Henderson <richard.henderson@linaro.org>' Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit c1f27a0c6ae4059a1d809e9c2bc4d47b823c32a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
#
40a205da |
| 20-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: emulate 64-bit ring 0 for linux-user if LM feature is set
32-bit binaries can run on a long mode processor even if the kernel is 64-bit, of course, and this can have slightly different
target/i386: emulate 64-bit ring 0 for linux-user if LM feature is set
32-bit binaries can run on a long mode processor even if the kernel is 64-bit, of course, and this can have slightly different behavior; for example, SYSCALL is allowed on Intel processors.
Allow reporting LM to programs running under user mode emulation, so that "-cpu" can be used with named CPU models even for qemu-i386 and even without disabling LM by hand.
Fortunately, most of the runtime code in QEMU has to depend on HF_LMA_MASK or on HF_CS64_MASK (which is anyway false for qemu-i386's 32-bit code segment) rather than TARGET_X86_64, therefore all that is needed is an update of linux-user's ring 0 setup.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1534 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
63fd8ef0 |
| 16-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: implement SYSCALL/SYSRET in 32-bit emulators
AMD supports both 32-bit and 64-bit SYSCALL/SYSRET, but the TCG only exposes it for 64-bit targets. For system emulation just reuse the hel
target/i386: implement SYSCALL/SYSRET in 32-bit emulators
AMD supports both 32-bit and 64-bit SYSCALL/SYSRET, but the TCG only exposes it for 64-bit targets. For system emulation just reuse the helper; for user-mode emulation the ABI is the same as "int $80".
The BSDs does not support any fast system call mechanism in 32-bit mode so add to bsd-user the same stub that FreeBSD has for 64-bit compatibility mode.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
6750485b |
| 20-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: implement RDPID in TCG
RDPID corresponds to a RDMSR(TSC_AUX); however, it is unprivileged so for user-mode emulation we must provide the value that the kernel places in the MSR. For Li
target/i386: implement RDPID in TCG
RDPID corresponds to a RDMSR(TSC_AUX); however, it is unprivileged so for user-mode emulation we must provide the value that the kernel places in the MSR. For Linux, it is a combination of the current CPU and the current NUMA node, both of which can be retrieved with getcpu(2). Also try sched_getcpu(), which might be there on the BSDs. If there is no portable way to retrieve the current CPU id from userspace, return 0.
RDTSCP is reimplemented as RDTSC + RDPID ECX; the differences in terms of serializability are not relevant to QEMU.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
53b9b4cc |
| 19-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: sysret and sysexit are privileged
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
75a02adf |
| 19-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: AMD only supports SYSENTER/SYSEXIT in 32-bit mode
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
fd5dcb1c |
| 19-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: Intel only supports SYSCALL/SYSRET in long mode
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
#
431c51e9 |
| 16-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: TCG supports WBNOINVD
WBNOINVD is the same as INVD or WBINVD as far as TCG is concerned, since there is no cache in TCG and therefore no invalidation side effect in WBNOINVD.
With resp
target/i386: TCG supports WBNOINVD
WBNOINVD is the same as INVD or WBINVD as far as TCG is concerned, since there is no cache in TCG and therefore no invalidation side effect in WBNOINVD.
With respect to SVM emulation, processors that do not support WBNOINVD will ignore the prefix and treat it as WBINVD, while those that support it will generate exactly the same vmexit.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
f9e0dbae |
| 20-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: do not accept RDSEED if CPUID bit absent
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paol
target/i386: do not accept RDSEED if CPUID bit absent
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
4d714d1a |
| 16-Jun-2023 |
Paolo Bonzini <pbonzini@redhat.com> |
target/i386: fix INVD vmexit
Due to a typo or perhaps a brain fart, the INVD vmexit was never generated. Fix it (but not that fixing just the typo would break both INVD and WBINVD, due to a case of
target/i386: fix INVD vmexit
Due to a typo or perhaps a brain fart, the INVD vmexit was never generated. Fix it (but not that fixing just the typo would break both INVD and WBINVD, due to a case of two wrongs making a right).
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
1dc7bb0e |
| 13-Jun-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
target/i386: Simplify i386_tr_init_disas_context()
Since cpu_mmu_index() is well-defined for user-only, we can remove the surrounding #ifdef'ry entirely.
Suggested-by: Richard Henderson <richard.he
target/i386: Simplify i386_tr_init_disas_context()
Since cpu_mmu_index() is well-defined for user-only, we can remove the surrounding #ifdef'ry entirely.
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230613133347.82210-2-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|