kqemu+amd64: fpudna in kernel mode

Jung-uk Kim jkim at FreeBSD.org
Wed Apr 11 17:22:15 UTC 2007

On Wednesday 11 April 2007 11:22 am, Andriy Gapon wrote:
> I get swarms of messages "fpudna in kernel mode" in system log when
> I run qemu with kqemu on FreeBSD 6.2 amd64 host with Windows XP
> 32-bit guest. I noticed that someone reported this problem a while
> ago:
> http://lists.freebsd.org/pipermail/freebsd-emulation/2006-February/

This happens because we do not allow FP instructions in kernel mode as 
the error message suggested.  Executing FP instructions in kernel 
mode requires expensive save/restore cycles for FP states.

> There is no harm done, but the messages are annoying and they might
> be indicative of some bigger issue.
> Note that I am running qemu like follows:
> $ qemu-system-x86_64 ... -m 512 -net tap -net nic -localtime
> there is no -kernel-kqemu option and "info kqemu" in qemu monitor
> says that it is enabled for user code.

-kernel-kqemu option does not work for FreeBSD and it is very 
experimental feature for Linux x86-64.  Since KQEMU is release under 
GPL recently, it can be fixed if someone's motivated enough, 
though. ;-)

> As I understand "fpudna" means "FPU device not available" and the
> message comes from here:
> http://fxr.watson.org/fxr/source/amd64/amd64/trap.c
> on T_DNA ("device not avaialble") _kernel_ fault.

You can ignore the complaints for now until we come up with better FP 
handling in kernel.

> BTW, not complaining about the following, but I think I should
> report it. When I use -kernel-kqemu option I get random crashes of
> the guest XP (BSOD) with diagnostics like the following (they
> vary):
> Looks like all three are caused by some sort of memory corruption
> or driver misbehavior according to the following:
> http://aumha.org/a/stop.htm

Windows guest is not supported by full virtualization mode, AFAIK.


BTW, it doesn't give you much performance gain as you may think:

'Best performances are achieved with Linux 2.4 kernels. Linux 2.6 
works but the performance gains are small.'

Even if we make it work with FreeBSD, I would expect similar results.

Jung-uk Kim

More information about the freebsd-ports mailing list