other: 0.195 semantic: 0.151 PID: 0.100 device: 0.075 performance: 0.067 files: 0.062 debug: 0.059 permissions: 0.057 graphic: 0.052 network: 0.051 vnc: 0.044 socket: 0.039 boot: 0.035 KVM: 0.014 debug: 0.801 files: 0.039 other: 0.026 semantic: 0.023 PID: 0.020 performance: 0.017 network: 0.016 graphic: 0.015 socket: 0.009 device: 0.009 boot: 0.008 permissions: 0.006 KVM: 0.006 vnc: 0.005 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