Migrating this bug from the old KVM bug tracker: http://sourceforge.net/tracker/?func=detail&aid=2905358&group_id=180599&atid=893831 Samuel Thibault wrote: "Apparently, KVM always enables CR0_NE, i.e. FPU errors are always reported via the EXCP10_COPR exception rather than via the FPU interrupt. This breaks operating systems which assume MS-DOS compatability mode, i.e. exceptions are always reported via the FPU interrupt (like GNU Mach)." I verified with Avi that this is still not supported, but patches are welcome. Anyone who would like to contribute and look for a project, feel free to look at this one.
Is this still the case? If yes, I would like to take a look and would you please to show me what I should test with GNU Mach as it looks like somebody is already booting it on top of KVM. http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00055.html Thanks, CJ
Well, yes, of course, I didn't wait for KVM to fix this bug and let people think that GNU Mach just does not work while it's actually KVM which has a bug... Right after submitting the bug I've made GNU Mach enable CR0_NE. The simplest way to test is probably to checkout revision 8d4fdfbe43628119fc87920239704fe3d240d8a2 of git://git.sv.gnu.org/hurd/gnumach.git and try to boot it e.g. using grub's multiboot command.
I followed the notes to install netinst.iso (http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/netinst.iso) on KVM but the guest OS hangs at "Select and install software" -- "Running post-installation trigger install-info" Is it a known issue? sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -net nic,model=rtl8139 -net user -hda hurd-install.qemu -cdrom netinst.iso -boot d -vnc :4 -no-kvm-irqchip
No, it is not a known issue. Which task(s) did you install? Note that you do not need to install GNU/Hurd to build GNU Mach, just git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git and autoreconf -i && ./configure && make. If you have a 64bit box, you need to cross-compile: CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ./configure --host=i686-unknown-linux-gnu Thinking again about, IIRC the kernel will just boot fine, it's only in some application use case that the issue shows up. I'll attach a patch which shows the CR0 value before and after Mach changes it. The 0x20 flag currently shows up both before and after. It should only show up after (because Mach sets it). To easily get the boot logs, pass console=com0 as kernel parameter during the multiboot command, that will direct logs to the serial port.
Created attachment 68962 [details] gnumach patch to show CR0 initialization