Re: New x86-Setup code breaks HVM-XEN boot
On Fri, 2007-08-31 at 09:54 +0200, Christian Ehrhardt wrote: > (XEN) (GUEST: 353) Detected Xen v3.0.3-1 I was unable to reproduce this problem on Xen 3.1.0 although I can't immediately see a particular changeset which obviously fixed it. There have been plenty of fixes to the emulator since 3.0.3 though so it's worth trying a newer version. In a later mail: > The problem is with the lgdt instruction. Apparently XEN does not keep > the contents of the 48-bit gdt_48 data structure that is passed to > lgdt in the XEN machine state. Instead it appears to save the > _address_ of the 48-bit descriptor somewhere. Unfortunately this data > happens to reside on the stack and is probably no longer availiable at > the time of the actual protected mode jump. The emulation of lgdt (in tools/firmware/vmxassist/vm86.c) looks sane enough on first glance (i.e. it saves the base and length not the pointer) although it isn't an area of the code I'm particularly familiar with. Ian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
On Fri, 2007-08-31 at 09:54 +0200, Christian Ehrhardt wrote: (XEN) (GUEST: 353) Detected Xen v3.0.3-1 I was unable to reproduce this problem on Xen 3.1.0 although I can't immediately see a particular changeset which obviously fixed it. There have been plenty of fixes to the emulator since 3.0.3 though so it's worth trying a newer version. In a later mail: The problem is with the lgdt instruction. Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. The emulation of lgdt (in tools/firmware/vmxassist/vm86.c) looks sane enough on first glance (i.e. it saves the base and length not the pointer) although it isn't an area of the code I'm particularly familiar with. Ian. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
Christian Ehrhardt wrote: I took the trouble to bisect (manually) exactly which change in the new boot code triggers this problem. The problem is with the lgdt instruction. Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. This is most likely a XEN-bug but given that there is a on line patch to work around this problem, the linux kernel should probably do this. My fix is to make the gdt_48 description in setup_gdt static (in setup_idt this is already the case). This allows the kernel to boot under XEN-hvm again. Would indeed be a Xen bug, and a pretty serious one too. Quite frankly, it reflects some pretty fundamental misconceptions about how x86 works. Sometimes it is a bit disappointing if quite some debuggin work results in a on line patch :-) Pleae consider applying. LOL, well, that's usually a good thing. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
Christian Ehrhardt wrote: I took the trouble to bisect (manually) exactly which change in the new boot code triggers this problem. The problem is with the lgdt instruction. Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. This is most likely a XEN-bug but given that there is a on line patch to work around this problem, the linux kernel should probably do this. My fix is to make the gdt_48 description in setup_gdt static (in setup_idt this is already the case). This allows the kernel to boot under XEN-hvm again. Would indeed be a Xen bug, and a pretty serious one too. Quite frankly, it reflects some pretty fundamental misconceptions about how x86 works. Sometimes it is a bit disappointing if quite some debuggin work results in a on line patch :-) Pleae consider applying. LOL, well, that's usually a good thing. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
Hi, On Thu, Aug 30, 2007 at 07:49:26AM -0700, H. Peter Anvin wrote: > Christian Ehrhardt wrote: > > > >Note the the xm console command terminates on its own, i.e. the guest > >machine seems to halt and not hang somewhere. > > > >I could verify that the real mode code up to the assembly code in > >pmjump.S is in fact executed. The problem appears to occur while > >enabling protected mode. I tried to put endless loops into the 32-bit > >setup code but these were apparently not reached. As far as I understand > >this, the protected mode jump in pmjump.S seems to jump into nowhere. > > > >I am willing to do tests with the XEN guest and send any additional > >information that might be helpful. However, I cannot change the XEN host > >at this time. > > > >Any suggestions? > > > > All of this point to a bug in the Xen emulation host. You're not saying > if you're on an Intel or AMD host, but on Intel, hardware > virtualization doesn't actually kick in until you're in protected mode > with all segments configured properly. This means all of pmjump.S runs > in an interpreter. A bug in that interpreter would cause what you observe. I took the trouble to bisect (manually) exactly which change in the new boot code triggers this problem. The problem is with the lgdt instruction. Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. This is most likely a XEN-bug but given that there is a on line patch to work around this problem, the linux kernel should probably do this. My fix is to make the gdt_48 description in setup_gdt static (in setup_idt this is already the case). This allows the kernel to boot under XEN-hvm again. Sometimes it is a bit disappointing if quite some debuggin work results in a on line patch :-) Pleae consider applying. regards Christian Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> diff --git a/arch/i386/boot/pm.c b/arch/i386/boot/pm.c index 6be9ca8..f7958f1 100644 --- a/arch/i386/boot/pm.c +++ b/arch/i386/boot/pm.c @@ -122,7 +122,7 @@ static void setup_gdt(void) /* DS: data, read/write, 4 GB, base 0 */ [GDT_ENTRY_BOOT_DS] = GDT_ENTRY(0xc093, 0, 0xf), }; - struct gdt_ptr gdt; + static struct gdt_ptr gdt; gdt.len = sizeof(boot_gdt)-1; gdt.ptr = (u32)_gdt + (ds() << 4); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
Hi, On Thu, Aug 30, 2007 at 07:49:26AM -0700, H. Peter Anvin wrote: Christian Ehrhardt wrote: Note the the xm console command terminates on its own, i.e. the guest machine seems to halt and not hang somewhere. I could verify that the real mode code up to the assembly code in pmjump.S is in fact executed. The problem appears to occur while enabling protected mode. I tried to put endless loops into the 32-bit setup code but these were apparently not reached. As far as I understand this, the protected mode jump in pmjump.S seems to jump into nowhere. I am willing to do tests with the XEN guest and send any additional information that might be helpful. However, I cannot change the XEN host at this time. Any suggestions? All of this point to a bug in the Xen emulation host. You're not saying if you're on an Intel or AMD host, but on Intel, hardware virtualization doesn't actually kick in until you're in protected mode with all segments configured properly. This means all of pmjump.S runs in an interpreter. A bug in that interpreter would cause what you observe. I took the trouble to bisect (manually) exactly which change in the new boot code triggers this problem. The problem is with the lgdt instruction. Apparently XEN does not keep the contents of the 48-bit gdt_48 data structure that is passed to lgdt in the XEN machine state. Instead it appears to save the _address_ of the 48-bit descriptor somewhere. Unfortunately this data happens to reside on the stack and is probably no longer availiable at the time of the actual protected mode jump. This is most likely a XEN-bug but given that there is a on line patch to work around this problem, the linux kernel should probably do this. My fix is to make the gdt_48 description in setup_gdt static (in setup_idt this is already the case). This allows the kernel to boot under XEN-hvm again. Sometimes it is a bit disappointing if quite some debuggin work results in a on line patch :-) Pleae consider applying. regards Christian Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED] diff --git a/arch/i386/boot/pm.c b/arch/i386/boot/pm.c index 6be9ca8..f7958f1 100644 --- a/arch/i386/boot/pm.c +++ b/arch/i386/boot/pm.c @@ -122,7 +122,7 @@ static void setup_gdt(void) /* DS: data, read/write, 4 GB, base 0 */ [GDT_ENTRY_BOOT_DS] = GDT_ENTRY(0xc093, 0, 0xf), }; - struct gdt_ptr gdt; + static struct gdt_ptr gdt; gdt.len = sizeof(boot_gdt)-1; gdt.ptr = (u32)boot_gdt + (ds() 4); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
Christian Ehrhardt wrote: (XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest state (0). (XEN) * VMCS Area ** (XEN)16-bit Guest-State Fields (XEN) 0x0800: 0x0018 0x0010 0x0018 0x0018 (XEN) 0x0808: 0x0018 0x0018 0x 0x0008 (XEN) 16-bit Host-State Fields (XEN) 0x0c00: 0xe010 0xe008 0xe010 0xe010 (XEN) 0x0c08: 0xe010 0xe010 0xe050 (XEN) 64-bit Control Fields (XEN) 0x2000: 0x00bd5000 0x 0x00bd4000 0x (XEN) 0x2004: 0x 0x 0x 0x (XEN) 0x2008: 0x 0x 0x 0x (XEN) 0x200c: 0x 0x -- -- (XEN) 0x2010: 0xd8ba12e5 0xffd5e176 0x 0x (XEN) 64-bit Guest-State Fields (XEN) 0x2800: 0x 0x 0x 0x (XEN) 32-bit Control Fields (XEN) 0x4000: 0x001f 0x0681e7fa 0x4008 0x (XEN) 0x4008: 0x 0x 0x0003edff 0x (XEN) 0x4010: 0x 0x11ff 0x 0x0020 (XEN) 0x4018: 0x 0x 0x (XEN) 32-bit RO Data Fields (XEN) 0x4400: 0x000c 0x8021 0x 0x00050033 (XEN) 0x4408: 0x 0x 0x0003 0x (XEN) 32-bit Guest-State Fields (XEN) 0x4800: 0x 0x 0x 0x (XEN) 0x4808: 0x 0x 0x 0x2067 (XEN) 0x4810: 0x6fb5 0x 0xd0ff 0xd0ff (XEN) 0x4818: 0xd0ff 0xd0ff 0xd0ff 0xd0ff (XEN) 0x4820: 0x0082 0x008b 0x 0x (XEN) 0x4828: 0x 0x (XEN) 32-bit Host-State Fields (XEN) 0x4c00: 0x (XEN) Natural 64-bit Control Fields (XEN) 0x6000: 0x 0x 0x00050033 0x0651 (XEN) 0x6008: 0x 0x 0x 0x (XEN) 64-bit RO Data Fields (XEN) 0x6400: 0x 0x00010002 0x003f7fd5 0x001a2000 (XEN) 0x6408: 0x000d11b2 0x (XEN) Natural 64-bit Guest-State Fields (XEN) 0x6800: 0x80050033 0x00bbfda0 0x2671 0x (XEN) 0x6808: 0x 0x 0x 0x (XEN) 0x6810: 0x 0x 0x000d7264 0x190df0bc (XEN) 0x6818: 0x 0x0400 0xf9e8 0x0010 (XEN) 0x6820: 0x00010002 0x 0x 0x (XEN) Natural 64-bit Host-State Fields (XEN) 0x6c00: 0x8005003b 0xa1f47000 0x26f0 0x (XEN) 0x6c08: 0x 0xff1cf380 0xfe80 0xffbeb080 (XEN) 0x6c10: 0x 0x 0xffbf3fe8 0xff14ab10 (XEN) ** (XEN) domain_crash_sync called from vmx.c:2154 (XEN) Domain 353 (vcpu#0) crashed on cpu#1: (XEN) [ Xen-3.0.3-1 x86_32p debug=n Not tainted ] (XEN) CPU:1 (XEN) EIP:0010:[<0010>] (XEN) EFLAGS: 00010002 CONTEXT: hvm (XEN) eax: 0010 ebx: ecx: f018 edx: 00050013 (XEN) esi: 000932a0 edi: 42d0 ebp: 000d esp: f9e8 (XEN) cr0: 00050033 cr4: 0651 cr3: 00bbfda0 cr2: (XEN) ds: 0018 es: 0018 fs: 0018 gs: 0018 ss: 0018 cs: 0010 Xen crashes because it thinks VMX should be handling this, but VMX doesn't think so (the exit reason is "invalid state".) At this point, paging is not yet enabled (CR0.PG = 0), but that is not natively supported by VMX. From a cursory look it doesn't appear as though that Xen has recognized that it's supposed to emulate this in one way or another. I'm on the road, so I don't have time for a more detailed analysis just at the moment. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
On Thu, Aug 30, 2007 at 12:04:09PM -0700, Jeremy Fitzhardinge wrote:
> Are there any messages on the xen console ("xm dmesg")? Or logs ("xm
> log")? What version of Xen are you using? What does your domain config
> file look like?
Domain Config:
| kernel = "hvmloader"
| builder='hvm'
| memory = 256
| shadow_memory = 16
| name = "ceh-lin-hvm"
| vif = [ 'type=ioemu, mac=00:16:3e:aa:00:08, bridge=xenbr0,
| model=ne2k_pci' ]
| disk = [ 'file:/xen/ceh-lin-hvm.img,ioemu:hda,w',
'file:/xen/cd/debian-40r0-i386-netinst.iso,hdc:cdrom,r' ]
| device_model = 'qemu-dm'
| boot="cad"
| sdl=0
| vnc=1
| vncunused=0
| stdvga=0
| serial='pty'
- xm dmesg output -
(XEN) vmx_do_launch(): GUEST_CR3<=00bbfda0, HOST_CR3<=a1f47000
(XEN) (GUEST: 353) HVM Loader
(XEN) (GUEST: 353) Detected Xen v3.0.3-1
(XEN) (GUEST: 353) Writing SMBIOS tables ...
(XEN) (GUEST: 353) Loading ROMBIOS ...
(XEN) (GUEST: 353) Loading Cirrus VGABIOS ...
(XEN) (GUEST: 353) Loading VMXAssist ...
(XEN) (GUEST: 353) VMX go ...
(XEN) (GUEST: 353) VMXAssist (Nov 2 2006)
(XEN) (GUEST: 353) Memory size 256 MB
(XEN) (GUEST: 353) E820 map:
(XEN) (GUEST: 353) - 0009F000 (RAM)
(XEN) (GUEST: 353) 0009F000 - 000A (Reserved)
(XEN) (GUEST: 353) 000A - 000C (Type 16)
(XEN) (GUEST: 353) 000F - 0010 (Reserved)
(XEN) (GUEST: 353) 0010 - 0FFF (RAM)
(XEN) (GUEST: 353) 0FFF - 0FFFA000 (ACPI Data)
(XEN) (GUEST: 353) 0FFFA000 - 0FFFD000 (ACPI NVS)
(XEN) (GUEST: 353) 0FFFD000 - 0FFFE000 (Type 19)
(XEN) (GUEST: 353) 0FFFE000 - 0000 (Type 18)
(XEN) (GUEST: 353) 0000 - 1000 (Type 17)
(XEN) (GUEST: 353) FEC0 - 0001 (Type 16)
(XEN) (GUEST: 353)
(XEN) (GUEST: 353) Start BIOS ...
(XEN) (GUEST: 353) Starting emulated 16-bit real-mode: ip=F000:FFF0
(XEN) (GUEST: 353) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $
(XEN) (GUEST: 353) Remapping master: ICW2 0x8 -> 0x20
(XEN) (GUEST: 353) Remapping slave: ICW2 0x70 -> 0x28
(XEN) (GUEST: 353) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert
Exp $
(XEN) (GUEST: 353) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07
15:55:26 $
(XEN) (GUEST: 353)
(XEN) (GUEST: 353) ata0-0: PCHS=5079/16/63 translation=lba LCHS=634/128/63
(XEN) (GUEST: 353) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (2500 MBytes)
(XEN) (GUEST: 353) ata0 slave: Unknown device
(XEN) (GUEST: 353) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom
(XEN) (GUEST: 353) ata1 slave: Unknown device
(XEN) (GUEST: 353)
(XEN) (GUEST: 353) Booting from Hard Disk...
(XEN) (GUEST: 353) KBD: unsupported int 16h function 03
(XEN) (GUEST: 353) *** int 15h function AX=E980, BX= not yet supported!
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=81
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=81
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=81
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=82
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=82
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=82
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=83
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=83
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=83
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=84
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=84
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=84
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=85
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=85
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=85
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=86
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=86
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=86
(XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=87
(XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=87
(XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=87
(XEN) (GUEST: 353) int13_harddisk: function 41, ELDL out of range 88
(XEN) (GUEST: 353) int13_harddisk: function 42, ELDL out of range 88
(XEN) (GUEST: 353) int13_harddisk: function 02, ELDL out of range 88
(XEN) (GUEST: 353) int13_harddisk: function 41, ELDL out of range 89
(XEN) (GUEST: 353) int13_harddisk: function 42, ELDL out of range 89
(XEN) (GUEST: 353) int13_harddisk: function 02, ELDL out of range 89
(XEN) (GUEST: 353) int13_harddisk: function 41, ELDL out of range 8A
(XEN) (GUEST: 353) int13_harddisk: function 42,
Re: New x86-Setup code breaks HVM-XEN boot
Christian Ehrhardt wrote: (XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest state (0). (XEN) * VMCS Area ** (XEN)16-bit Guest-State Fields (XEN) 0x0800: 0x0018 0x0010 0x0018 0x0018 (XEN) 0x0808: 0x0018 0x0018 0x 0x0008 (XEN) 16-bit Host-State Fields (XEN) 0x0c00: 0xe010 0xe008 0xe010 0xe010 (XEN) 0x0c08: 0xe010 0xe010 0xe050 (XEN) 64-bit Control Fields (XEN) 0x2000: 0x00bd5000 0x 0x00bd4000 0x (XEN) 0x2004: 0x 0x 0x 0x (XEN) 0x2008: 0x 0x 0x 0x (XEN) 0x200c: 0x 0x -- -- (XEN) 0x2010: 0xd8ba12e5 0xffd5e176 0x 0x (XEN) 64-bit Guest-State Fields (XEN) 0x2800: 0x 0x 0x 0x (XEN) 32-bit Control Fields (XEN) 0x4000: 0x001f 0x0681e7fa 0x4008 0x (XEN) 0x4008: 0x 0x 0x0003edff 0x (XEN) 0x4010: 0x 0x11ff 0x 0x0020 (XEN) 0x4018: 0x 0x 0x (XEN) 32-bit RO Data Fields (XEN) 0x4400: 0x000c 0x8021 0x 0x00050033 (XEN) 0x4408: 0x 0x 0x0003 0x (XEN) 32-bit Guest-State Fields (XEN) 0x4800: 0x 0x 0x 0x (XEN) 0x4808: 0x 0x 0x 0x2067 (XEN) 0x4810: 0x6fb5 0x 0xd0ff 0xd0ff (XEN) 0x4818: 0xd0ff 0xd0ff 0xd0ff 0xd0ff (XEN) 0x4820: 0x0082 0x008b 0x 0x (XEN) 0x4828: 0x 0x (XEN) 32-bit Host-State Fields (XEN) 0x4c00: 0x (XEN) Natural 64-bit Control Fields (XEN) 0x6000: 0x 0x 0x00050033 0x0651 (XEN) 0x6008: 0x 0x 0x 0x (XEN) 64-bit RO Data Fields (XEN) 0x6400: 0x 0x00010002 0x003f7fd5 0x001a2000 (XEN) 0x6408: 0x000d11b2 0x (XEN) Natural 64-bit Guest-State Fields (XEN) 0x6800: 0x80050033 0x00bbfda0 0x2671 0x (XEN) 0x6808: 0x 0x 0x 0x (XEN) 0x6810: 0x 0x 0x000d7264 0x190df0bc (XEN) 0x6818: 0x 0x0400 0xf9e8 0x0010 (XEN) 0x6820: 0x00010002 0x 0x 0x (XEN) Natural 64-bit Host-State Fields (XEN) 0x6c00: 0x8005003b 0xa1f47000 0x26f0 0x (XEN) 0x6c08: 0x 0xff1cf380 0xfe80 0xffbeb080 (XEN) 0x6c10: 0x 0x 0xffbf3fe8 0xff14ab10 (XEN) ** (XEN) domain_crash_sync called from vmx.c:2154 (XEN) Domain 353 (vcpu#0) crashed on cpu#1: (XEN) [ Xen-3.0.3-1 x86_32p debug=n Not tainted ] (XEN) CPU:1 (XEN) EIP:0010:[0010] (XEN) EFLAGS: 00010002 CONTEXT: hvm (XEN) eax: 0010 ebx: ecx: f018 edx: 00050013 (XEN) esi: 000932a0 edi: 42d0 ebp: 000d esp: f9e8 (XEN) cr0: 00050033 cr4: 0651 cr3: 00bbfda0 cr2: (XEN) ds: 0018 es: 0018 fs: 0018 gs: 0018 ss: 0018 cs: 0010 Xen crashes because it thinks VMX should be handling this, but VMX doesn't think so (the exit reason is invalid state.) At this point, paging is not yet enabled (CR0.PG = 0), but that is not natively supported by VMX. From a cursory look it doesn't appear as though that Xen has recognized that it's supposed to emulate this in one way or another. I'm on the road, so I don't have time for a more detailed analysis just at the moment. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New x86-Setup code breaks HVM-XEN boot
On Thu, Aug 30, 2007 at 12:04:09PM -0700, Jeremy Fitzhardinge wrote: Are there any messages on the xen console (xm dmesg)? Or logs (xm log)? What version of Xen are you using? What does your domain config file look like? Domain Config: | kernel = hvmloader | builder='hvm' | memory = 256 | shadow_memory = 16 | name = ceh-lin-hvm | vif = [ 'type=ioemu, mac=00:16:3e:aa:00:08, bridge=xenbr0, | model=ne2k_pci' ] | disk = [ 'file:/xen/ceh-lin-hvm.img,ioemu:hda,w', 'file:/xen/cd/debian-40r0-i386-netinst.iso,hdc:cdrom,r' ] | device_model = 'qemu-dm' | boot=cad | sdl=0 | vnc=1 | vncunused=0 | stdvga=0 | serial='pty' - xm dmesg output - (XEN) vmx_do_launch(): GUEST_CR3=00bbfda0, HOST_CR3=a1f47000 (XEN) (GUEST: 353) HVM Loader (XEN) (GUEST: 353) Detected Xen v3.0.3-1 (XEN) (GUEST: 353) Writing SMBIOS tables ... (XEN) (GUEST: 353) Loading ROMBIOS ... (XEN) (GUEST: 353) Loading Cirrus VGABIOS ... (XEN) (GUEST: 353) Loading VMXAssist ... (XEN) (GUEST: 353) VMX go ... (XEN) (GUEST: 353) VMXAssist (Nov 2 2006) (XEN) (GUEST: 353) Memory size 256 MB (XEN) (GUEST: 353) E820 map: (XEN) (GUEST: 353) - 0009F000 (RAM) (XEN) (GUEST: 353) 0009F000 - 000A (Reserved) (XEN) (GUEST: 353) 000A - 000C (Type 16) (XEN) (GUEST: 353) 000F - 0010 (Reserved) (XEN) (GUEST: 353) 0010 - 0FFF (RAM) (XEN) (GUEST: 353) 0FFF - 0FFFA000 (ACPI Data) (XEN) (GUEST: 353) 0FFFA000 - 0FFFD000 (ACPI NVS) (XEN) (GUEST: 353) 0FFFD000 - 0FFFE000 (Type 19) (XEN) (GUEST: 353) 0FFFE000 - 0000 (Type 18) (XEN) (GUEST: 353) 0000 - 1000 (Type 17) (XEN) (GUEST: 353) FEC0 - 0001 (Type 16) (XEN) (GUEST: 353) (XEN) (GUEST: 353) Start BIOS ... (XEN) (GUEST: 353) Starting emulated 16-bit real-mode: ip=F000:FFF0 (XEN) (GUEST: 353) rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ (XEN) (GUEST: 353) Remapping master: ICW2 0x8 - 0x20 (XEN) (GUEST: 353) Remapping slave: ICW2 0x70 - 0x28 (XEN) (GUEST: 353) VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $ (XEN) (GUEST: 353) HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ (XEN) (GUEST: 353) (XEN) (GUEST: 353) ata0-0: PCHS=5079/16/63 translation=lba LCHS=634/128/63 (XEN) (GUEST: 353) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (2500 MBytes) (XEN) (GUEST: 353) ata0 slave: Unknown device (XEN) (GUEST: 353) ata1 master: QEMU CD-ROM ATAPI-4 CD-Rom/DVD-Rom (XEN) (GUEST: 353) ata1 slave: Unknown device (XEN) (GUEST: 353) (XEN) (GUEST: 353) Booting from Hard Disk... (XEN) (GUEST: 353) KBD: unsupported int 16h function 03 (XEN) (GUEST: 353) *** int 15h function AX=E980, BX= not yet supported! (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=81 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=81 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=81 (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=82 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=82 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=82 (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=83 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=83 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=83 (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=84 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=84 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=84 (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=85 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=85 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=85 (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=86 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=86 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=86 (XEN) (GUEST: 353) int13_harddisk: function 41, unmapped device for ELDL=87 (XEN) (GUEST: 353) int13_harddisk: function 42, unmapped device for ELDL=87 (XEN) (GUEST: 353) int13_harddisk: function 02, unmapped device for ELDL=87 (XEN) (GUEST: 353) int13_harddisk: function 41, ELDL out of range 88 (XEN) (GUEST: 353) int13_harddisk: function 42, ELDL out of range 88 (XEN) (GUEST: 353) int13_harddisk: function 02, ELDL out of range 88 (XEN) (GUEST: 353) int13_harddisk: function 41, ELDL out of range 89 (XEN) (GUEST: 353) int13_harddisk: function 42, ELDL out of range 89 (XEN) (GUEST: 353) int13_harddisk: function 02, ELDL out of range 89 (XEN) (GUEST: 353) int13_harddisk: function 41, ELDL out of range 8A (XEN) (GUEST: 353) int13_harddisk: function 42, ELDL out of range 8A
