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. Paolo
