Bug 616272 - KVM crashes inside SeaBIOS when attempting to boot MS-DOS
Summary: KVM crashes inside SeaBIOS when attempting to boot MS-DOS
Alias: None
Product: Fedora
Classification: Fedora
Component: seabios   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Justin M. Forbes
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-20 01:06 UTC by H. Peter Anvin
Modified: 2011-06-29 13:15 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 622350 (view as bug list)
Last Closed: 2011-06-29 13:15:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description H. Peter Anvin 2010-07-20 01:06:33 UTC
Description of problem:

KVM crashes when booting an MS-DOS 6.22 guest on an Intel host.  This happens inside SeaBIOS; apparently SeaBIOS puts the hardware in a state KVM can't handle.

Version-Release number of selected component (if applicable):


How reproducible:

Every time

Steps to Reproduce:
1. Create an MS-DOS 6.22 boot disk
2. Boot it.
Actual results:
kvm: unhandled exit 80000021
kvm_run returned -22

"info registers" in the Qemu console shows that the error happens inside SeaBIOS, immediately after a return to real mode.

Expected results:
MS-DOS booting.

Additional info:
Happens with both hard disk and floppy disk images.  No config.sys or autoexec.bat needed in the guest.

CPU information (x4 cores x2 threads):
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Core(TM) i7 CPU         940  @ 2.93GHz
stepping        : 4
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid       
bogomips        : 5853.09                                                                   
clflush size    : 64                                                                        
cache_alignment : 64                                                                        
address sizes   : 36 bits physical, 48 bits virtual                                         
power management:

Comment 1 H. Peter Anvin 2010-07-26 23:08:27 UTC
Note: "Plain" Qemu handles the same thing fine.

Comment 2 H. Peter Anvin 2010-07-31 01:21:18 UTC
(qemu) info registers
EAX=00000010 EBX=00000008 ECX=e0100000 EDX=00000508
ESI=00000020 EDI=e0100020 EBP=00000008 ESP=000004d4
EIP=0000f4a7 EFL=00000002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 0000f300
CS =f000 000f0000 0000ffff 0000f300
SS =8e01 0008e010 0000ffff 0000f300
DS =8ec9 0008ec96 0000ffff 0000f300
FS =0000 00000000 0000ffff 0000f300                   
GS =0000 00000000 0000ffff 0000f300
LDT=0000 00000000 0000ffff 00008200
TR =0000 feffd000 00002088 00008b00
GDT=     0008ec66 0000002f
IDT=     000f8560 00000000                            
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000       
DR6=ffff0ff0 DR7=00000400                                 
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000                        
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000                        
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000             
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

Comment 3 Justin M. Forbes 2010-08-11 21:16:37 UTC
Which version of seabios is this using?

Comment 4 H. Peter Anvin 2010-08-13 17:32:37 UTC

Comment 5 H. Peter Anvin 2010-08-13 17:43:46 UTC
Looking through the register dump, one thing that stands out to me is that ds_base is not 16-byte aligned - that is probably the part that makes KVM reject the state.

Comment 6 Gleb Natapov 2010-08-15 11:46:05 UTC
can you test if latest seabios from  git://git.linuxtogo.org/home/kevin/seabios.git works?

Comment 7 H. Peter Anvin 2010-08-24 00:59:46 UTC
Tested it, it works.

Comment 8 Bug Zapper 2011-06-01 13:23:42 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 9 Bug Zapper 2011-06-29 13:15:01 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.