On 11/18/25 14:07, Paolo Bonzini wrote:
On Tue, Nov 18, 2025 at 9:31 AM Richard Henderson
<[email protected]> wrote:
On 11/17/25 12:32, Paolo Bonzini wrote:
On 11/17/25 10:42, Richard Henderson wrote:
On 11/15/25 01:26, Paolo Bonzini wrote:
-void cpu_vmexit(CPUX86State *env, uint32_t exit_code, uint64_t exit_info_1,
+void cpu_vmexit(CPUX86State *env, uint64_t exit_code, uint64_t exit_info_1,
uintptr_t retaddr)
{
CPUState *cs = env_cpu(env);
@@ -732,7 +732,7 @@ void cpu_vmexit(CPUX86State *env, uint32_t exit_code,
uint64_t
exit_info_1,
qemu_log_mask(CPU_LOG_TB_IN_ASM, "vmexit(%08x, %016" PRIx64 ", %016"
PRIx64 ", " TARGET_FMT_lx ")!\n",
- exit_code, exit_info_1,
+ (uint32_t)exit_code, exit_info_1,
Why cast instead of printing all 64 bits?
Because in practice exit_code is either a very small negative value (-1...-4)
or a
positive value. For QEMU in addition the positive value will also be small
(less than 16
bits); values between 0x8000_0000 and 0xffff_ffff could happen in principle but
are for
use by software and by the processor[1]. So the high 32 bits are basically
unused, and
the cast removes eight zeroes or f's from the log.
Then maybe you really want the signed int64_t?
The problem is not in the type (int64_t or uint64_t work equally well,
they're all just constants), it's in the format string. Positive codes
are written in hexadecimal in the manual, so:
- %ld makes it hard to match the positive codes in the manual
- %lx still prints a -1 as ffffffffffffffff.
So all the cast is doing is making the log more readable.
Ok then.
r~
