Qemu, div by zero, mxcsr register

The MXCSR register is described in the Intel® 64 and IA-32 Architectures Software Developer’s Manual

On modern x86 processors the compiler maps floating point operations as scalar SIMD, using the same resources that vector (SSE) instructions use.

The MXCSR register controls the operation of both scalar and vector (SSE) floating point instructions. I've included the relevant section describing the MXCSR below. MXCSR[9] is the Divide-by-Zero Mask, if cleared (0) then the CPU will raise an exception when Divide by Zero is detected. When you are running in a virtual machine exceptions are "virtualized", they are handled by a "hypervisor", KVM in your case. The hypervisor then decides whether to reflect the exception back to the guest virtual machine. My theory is that the Divide-by-Zero Mask is cleared, the exception is raised, KVM and/or QEMU is clearing the flag that indicates a divide by zero exception happened MXCSR[2] and resumes your virtual machine. This is therefore likely a bug in KVM/QEMU.

You could issue fegetexcept() before the DivideByZero() to find out if the Divide-By-Zero exception is masked (1) or not (0). If it is not masked then you could use fedisableexcept() to mask it.

When QEMU works as a software emulation.

From http://qemu.weilnetz.de/qemu-tech.html#intro_005fx86_005femulation.

2.8 Exception support

longjmp() is used when an exception such as division by zero is encountered.

The host SIGSEGV and SIGBUS signal handlers are used to get invalid memory accesses. The simulated program counter is found by retranslating the corresponding basic block and by looking where the host program counter was at the exception point.

The virtual CPU cannot retrieve the exact EFLAGS register because in some cases it is not computed because of condition code optimisations. It is not a big concern because the emulated code can still be restarted in any cases.

Looks like the FPU state is lost too and the bits indicating what is the FPU exception - division by zero/invalid arguments in your case are lost. And QEMU could not properly emulate fetestexcept. Hence the result.

When QEMU works using hardware virtualization - KVM, the floating point exceptions are handled properly - so the test is correct.

-- edit:Other posibility is that the exceptions mode is initialized differently:You may try to add that to enable div by zero exception.feenableexcept (FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW);

I am not sure about the logic, but QEMU is software implementation and KVM is hardware support. So may be in software implementation the bit is not set because of floating point mis-calculation or storing floating point value..