Bug 23992

Summary:	RFE: Add support for MS-DOS FPU compatibility mode
Product:	Virtualization	Reporter:	Jes Sorensen (Jes.Sorensen)
Component:	kvm	Assignee:	virtualization_kvm
Status:	RESOLVED OBSOLETE
Severity:	enhancement	CC:	alan, cyclonusj, samuel.thibault
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	-	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	gnumach patch to show CR0 initialization

Description Jes Sorensen 2010-11-29 16:14:40 UTC

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.

Comment 1 CJ 2011-08-12 08:53:42 UTC

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

Comment 2 Samuel Thibault 2011-08-12 09:47:56 UTC

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.

Comment 3 CJ 2011-08-15 02:55:24 UTC

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

Comment 4 Samuel Thibault 2011-08-15 18:31:28 UTC

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.

Comment 5 Samuel Thibault 2011-08-15 18:34:43 UTC

Created attachment 68962 [details]
gnumach patch to show CR0 initialization