Bug 506924 - [RHEL5.4 Xen]: Fully virtualized Minix guest fails to boot
[RHEL5.4 Xen]: Fully virtualized Minix guest fails to boot
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.4
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Xen Maintainance List
Virtualization Bugs
:
Depends On: 580945
Blocks: 514491
  Show dependency treegraph
 
Reported: 2009-06-19 06:38 EDT by Osier Yang
Modified: 2014-03-26 21:01 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-17 23:12:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
blocked at booting screen picture. (141.72 KB, image/png)
2009-06-19 06:40 EDT, Osier Yang
no flags Details
dumped libvirt xml of minix 3. (1.21 KB, text/plain)
2009-06-19 07:07 EDT, Osier Yang
no flags Details
minix virt-image xml (457 bytes, text/plain)
2009-06-19 07:08 EDT, Osier Yang
no flags Details
MS-DOS.vmx (832 bytes, text/plain)
2009-06-19 07:09 EDT, Osier Yang
no flags Details
Screenshot of minix boot after patching vmxassist (9.93 KB, image/png)
2010-04-09 09:32 EDT, Michal Novotny
no flags Details

  None (edit)
Description Osier Yang 2009-06-19 06:38:10 EDT
Description of problem:

python-virtinst version: python-virtinst-0.400.3-1.el5
xen version            : xen-3.0.3-86.el5
libvirt version        : libvirt-0.6.3-3.el5
virt-manager version   : virt-manager-0.6.1-1.el5

system                 : Red Hat Enterprise Linux Server release 5.4 Beta (Tikanga)
kernel info            : Linux 2.6.18-151.el5xen #1 SMP Wed May 27 16:33:19 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux



How reproducible:


Steps to Reproduce:
1. download minix vmware virtual machine from http://www.minix3.org/download/minix3_1_2a_vmware.zip
2. unzip minix3_1_2a_vmware.zip
3. cd minix
4. virt-convert -i vmx -o virt-image MS-DOS.vmx
5. cd minix
6. virt-image --name minix minix.virt-image.xml
7. use virt-manager to watch the guest status
  
Actual results:
  the guest was started normally, we can see minix 3.   

Expected results:
  blocked at booting screen, always there, see attachment.

Additional info:
  have installed VMware Workstation 6.5.1 build-126130 on RHEL5.4 Beta (Tikanga), and tried to open the minix, the result is that it can be started successfully.

  And I also created a new RHEL5.3-Server virtual machine using VMware Workstation. then use it as the test source, found it can be started normally.
Comment 1 Osier Yang 2009-06-19 06:40:12 EDT
Created attachment 348631 [details]
blocked at booting screen picture.
Comment 2 Daniel Berrange 2009-06-19 06:44:14 EDT
Can you provide the 'MS-DOS.vmx'  file from the appliance, the generated  minix.virt-image.xml file and the output from 'virsh dumpxml minix' so we can see the final libvirt XML
Comment 3 Osier Yang 2009-06-19 07:07:49 EDT
Created attachment 348636 [details]
dumped libvirt xml of minix 3.
Comment 4 Osier Yang 2009-06-19 07:08:22 EDT
Created attachment 348637 [details]
minix virt-image xml
Comment 5 Osier Yang 2009-06-19 07:09:34 EDT
Created attachment 348638 [details]
MS-DOS.vmx
Comment 6 Daniel Berrange 2009-06-19 07:38:05 EDT
I'd say there is a non-trivial chance that the pre-installed VMWare image for Minix simply won't automatically adapt to cope with the Xen virtual hardware model.   Then again, perhaps Xen won't rnu Minix at all.

I think it'd be worth testing the bootable ISO install image of Minix first to make sure Minix itself does work in Xen, before trying to further troubleshoot the VMware image usage, eg try the IDE ISO from here

http://www.minix3.org/download/
Comment 7 Chris Lalancette 2009-06-19 07:46:03 EDT
(In reply to comment #6)
> I'd say there is a non-trivial chance that the pre-installed VMWare image for
> Minix simply won't automatically adapt to cope with the Xen virtual hardware
> model.   Then again, perhaps Xen won't rnu Minix at all.
> 
> I think it'd be worth testing the bootable ISO install image of Minix first to
> make sure Minix itself does work in Xen, before trying to further troubleshoot
> the VMware image usage, eg try the IDE ISO from here
> 
> http://www.minix3.org/download/  

Yeah, totally agreed.  I doubt anyone has ever tried Minix on RHEL-5 Xen before, so it's certainly possible that it doesn't work at all, in which case this would be a "kernel-xen" bug, in all likelihood.

Chris Lalancette
Comment 8 Osier Yang 2009-06-22 04:59:53 EDT
It depends on whether xen can start minix normally, I will test it (install a minix guest on xen). then tell you the result.

if the minix can run normally on xen, it's a bug of virt-convert.
Comment 9 Osier Yang 2009-07-06 00:33:51 EDT
have tested by installing a minix3 on xen, it failed. the problem is same----blocked at booting screen, always there.

so I think it's not a bug of virt-convert, but caused by xen don't support minix3.
Comment 10 Chris Lalancette 2009-07-06 03:55:18 EDT
OK, thanks for confirming.  I'll move it to the xen component for now, since that is one place where the problem might actually be (another is kernel-xen, I just don't know yet).

Chris Lalancette
Comment 13 Michal Novotny 2010-03-22 08:48:12 EDT
(In reply to comment #10)
> OK, thanks for confirming.  I'll move it to the xen component for now, since
> that is one place where the problem might actually be (another is kernel-xen, I
> just don't know yet).
> 
> Chris Lalancette    

Well, I don't know where exactly this could be but I tried it and it's saying something about 3 seconds to boot the first option. The problem here is that it's stuck even before I can enter a digit to choose what version of MINIX to boot so this is really a bug that's xen related. I don't know whether it's xen or kernel-xen but there may be some call to the emulated BIOS environment, HVMAssist BIOS, that is not supported by it. But I can't see anything helpful in qemu-dm.{$PID}.log and xend.log so I don't really know where to look. Maybe more investigation in qemu-dm code is necessary and I also should add some logging to this one. I'm going to take this one and try to investigate.

Michal
Comment 14 Michal Novotny 2010-04-09 08:51:55 EDT
(In reply to comment #13)
> (In reply to comment #10)
> > OK, thanks for confirming.  I'll move it to the xen component for now, since
> > that is one place where the problem might actually be (another is kernel-xen, I
> > just don't know yet).
> > 
> > Chris Lalancette    
> 
> Well, I don't know where exactly this could be but I tried it and it's saying
> something about 3 seconds to boot the first option. The problem here is that
> it's stuck even before I can enter a digit to choose what version of MINIX to
> boot so this is really a bug that's xen related. I don't know whether it's xen
> or kernel-xen but there may be some call to the emulated BIOS environment,
> HVMAssist BIOS, that is not supported by it. But I can't see anything helpful
> in qemu-dm.{$PID}.log and xend.log so I don't really know where to look. Maybe
> more investigation in qemu-dm code is necessary and I also should add some
> logging to this one. I'm going to take this one and try to investigate.
> 
> Michal    

I've been doing some investigation of this one and finally I have added logging support for the qemu-dm process to log all the outputs to port port 0xE9 using the do_outp() function in helper2.c code. What I was thinking was confirmed, There is a halt called from some EIP instruction since there is a "Unknown opcode at 9317:0412=0x93582" message when trying to boot Minix. It appears some important instruction used by Minix is not emulated at the time resulting in halt of the virtual machine.

Michal
Comment 15 Paolo Bonzini 2010-04-09 09:09:20 EDT
This is happening in vmxassist.  It is not a complete vm86 implementation, and it doesn't handle some exits.  For HLT we can afford doing nothing, the only problem is that the guest will busy wait while in real mode.  You just need something like:

                case 0xF4: /* hlt */
                        TRACE((regs, regs->eip - eip, "hlt"));
                        return OPC_EMULATED;
Comment 16 Michal Novotny 2010-04-09 09:32:20 EDT
Created attachment 405545 [details]
Screenshot of minix boot after patching vmxassist

(In reply to comment #15)
> This is happening in vmxassist.  It is not a complete vm86 implementation, and
> it doesn't handle some exits.  For HLT we can afford doing nothing, the only
> problem is that the guest will busy wait while in real mode.  You just need
> something like:
> 
>                 case 0xF4: /* hlt */
>                         TRACE((regs, regs->eip - eip, "hlt"));
>                         return OPC_EMULATED;    

Thanks, I did try to emulate the halt instruction and it passed this part but it's still not working. It's stuck a little later but still stuck. No real output is present in the debug file from the hvmloader/vmxassist:

HVM Loader
Detected Xen v3.1.2-194.el5
Writing SMBIOS tables ...
Loading ROMBIOS ...
8876 bytes of ROMBIOS high-memory extensions:
  Relocating to 0x1ffac00-0x1ffceac ... done
PCI-ISA link 0 routed to IRQ5
PCI-ISA link 1 routed to IRQ7
PCI-ISA link 2 routed to IRQ10
PCI-ISA link 3 routed to IRQ11
pci dev 01:1 bar 20 size 00000010: 0000c001
pci dev 01:2 INTA->IRQ7
pci dev 02:0 bar 10 size 02000000: f0000008
pci dev 02:0 bar 14 size 00001000: f2000000
pci dev 03:0 bar 10 size 00000100: 0000c101
pci dev 03:0 bar 14 size 01000000: f3000008
pci dev 03:0 INTA->IRQ11
Creating MP tables ...
Loading Cirrus VGABIOS ...
Loading ACPI ...
BIOS map:
 c0000-c8003: VGA BIOS
 d0000-d5403: VMXAssist
 e9000-e9171: SMBIOS tables
 ea000-eb2cf: ACPI tables
 f0000-fffff: Main BIOS
Loading VMXAssist ...
VMX go ...
VMXAssist (Mar  9 2010)
Memory size 31 MB
E820 map:
0000000000000000 - 000000000009FC00 (RAM)
000000000009FC00 - 00000000000A0000 (Reserved)
00000000000E0000 - 0000000000100000 (Reserved)
0000000000100000 - 0000000001FFAC00 (RAM)
0000000001FFAC00 - 0000000002000000 (Reserved)

Start BIOS ...
Starting emulated 16-bit real-mode: ip=F000:FFF0
 rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
Remapping master: ICW2 0x8 -> 0x20
Remapping slave: ICW2 0x70 -> 0x28
VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $

HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $

ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
ata0  slave: Unknown device

Booting from Hard Disk...
... and that's all ...

It seems like this is purely the guest issue. The guest is stuck with the screen attached to this comment and that's all. It's using converted image like in comment #0 but since I don't see anything in the vmxassist/hvmloader output and nothing in the qemu-dm.{PID}.log so I don't know now.

Thanks for the talk about instructions, emulation, vm86 etc. anyway :)
Michal
Comment 17 Paolo Bonzini 2010-04-09 10:32:27 EDT
> It seems like this is purely the guest issue. The guest is stuck with the
> screen attached to this comment and that's all

This says the opposite to me, it's likely another bug in qemu or the hypervisor.  xenctx says that cs=0x0030 so it's already in protected mode and vmxassist is out of the picture.
Comment 18 Michal Novotny 2010-04-09 11:15:26 EDT
(In reply to comment #17)
> > It seems like this is purely the guest issue. The guest is stuck with the
> > screen attached to this comment and that's all
> 
> This says the opposite to me, it's likely another bug in qemu or the
> hypervisor.  xenctx says that cs=0x0030 so it's already in protected mode and
> vmxassist is out of the picture.    

Yeah, this can be. Well, but under the qemu itself (no kvm involved) it runs OK but with qemu-kvm (respectively KVM enabled) it does not. Same with Xen.

For the HLT instruction emulation patch attached to bug 580945 is necessary.

Michal
Comment 19 Osier Yang 2011-05-17 23:12:28 EDT
I close this as WONTFIX, as minix is not supported guest, and it costs quite a lot time to discover the real problem.

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