x86: 0.950 i386: 0.943 kernel: 0.896 assembly: 0.842 architecture: 0.838 ppc: 0.779 register: 0.635 device: 0.543 semantic: 0.396 PID: 0.373 files: 0.369 network: 0.367 socket: 0.356 risc-v: 0.322 performance: 0.315 boot: 0.303 virtual: 0.252 vnc: 0.251 permissions: 0.246 graphic: 0.236 debug: 0.226 arm: 0.215 mistranslation: 0.196 user-level: 0.196 TCG: 0.164 hypervisor: 0.151 VMM: 0.151 peripherals: 0.114 KVM: 0.008 -------------------- x86: 0.996 debug: 0.929 i386: 0.906 virtual: 0.269 assembly: 0.120 files: 0.033 kernel: 0.017 hypervisor: 0.016 semantic: 0.012 PID: 0.010 user-level: 0.007 architecture: 0.007 performance: 0.007 network: 0.006 graphic: 0.005 TCG: 0.004 register: 0.004 socket: 0.002 device: 0.002 boot: 0.002 VMM: 0.001 ppc: 0.001 permissions: 0.001 KVM: 0.001 peripherals: 0.001 vnc: 0.000 mistranslation: 0.000 risc-v: 0.000 arm: 0.000 x86: retf or iret pagefault sets wrong error code With a x86_64 or i386 guest, non-KVM, when trying to execute a "iret/iretq/retf" instruction in userspace with invalid stack pointer (under a protected mode OS, like Linux), wrong bits are set in the pushed error code; bit 2 is not set, indicating the error comes from kernel space. If the guest OS is using this flag to decide whether this was a kernel or user page fault, it will mistakenly decide a kernel has irrecoverably faulted, possibly causing guest OS panic. How to reproduce the problem a guest (non-KVM) Linux: Note, on recent Linux kernel version, this needs a CPU with SMAP support (eg. -cpu max) $ cat tst.c int main() { __asm__ volatile ( "mov $0,%esp\n" "retf" ); return 0; } $ gcc tst.c $ ./a.out Killed "dmesg" shows the kernel has in fact triggered a "BUG: unable to handle kernel NULL pointer dereference...", but it has "recovered" by killing the faulting process (see attached screenshot). Using self-compiled qemu from git: commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) Author: Peter Maydell