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.
Paolo
[1] see for example arch/x86/include/uapi/asm/svm.h in Linux:
#define SVM_VMGEXIT_MMIO_READ 0x80000001
#define SVM_VMGEXIT_MMIO_WRITE 0x80000002
#define SVM_VMGEXIT_NMI_COMPLETE 0x80000003
#define SVM_VMGEXIT_AP_HLT_LOOP 0x80000004
#define SVM_VMGEXIT_AP_JUMP_TABLE 0x80000005
#define SVM_VMGEXIT_PSC 0x80000010
#define SVM_VMGEXIT_GUEST_REQUEST 0x80000011
#define SVM_VMGEXIT_EXT_GUEST_REQUEST 0x80000012
#define SVM_VMGEXIT_AP_CREATION 0x80000013
#define SVM_VMGEXIT_SNP_RUN_VMPL 0x80000018
#define SVM_VMGEXIT_SAVIC 0x8000001a
#define SVM_VMGEXIT_HV_FEATURES 0x8000fffd
#define SVM_VMGEXIT_TERM_REQUEST 0x8000fffe
#define SVM_VMGEXIT_UNSUPPORTED_EVENT 0x8000ffff
#define SVM_EXIT_SW 0xf0000000
SVM_VMGEXIT_* values are actually stored by the guest in its own memory,
not by the processor; whereas SVM_EXIT_SW is only used in nested
virtualization scenarios and will not be passed to cpu_vmexit.
