2.6.22 x86_64 : kernel initial decompression hangs on vmware

2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Gabriel Barazer]

Hi,

After upgrading kernel to 2.6.22 on a Vmware workstation guest version 
5.5 and 6 , the kernel decompression stage ("Decompressing Linux...") is 
hanging for a very long time (~5 minutes) before finally  succeeding 
(displaying "done.\nBooting the kernel.\n"). During this time, the VM 
process is eating all the CPU time during the decompression, like an 
infinite loop.
Between these 2 strings is the gunzip() function at 
boot/compressed/misc.c which does the real job, and the problem seemed 
to appear since commit 1ab60e0f72f71ec54831e525a3e1154f1c092408. 
(2.6.22-rc1 hangs, 2.6.21.6 works). The problem occurs with or without 
CONFIG_RELOCATABLE enabled.

What are the possible solutions to confirm where the problem is coming 
from ?

Thanks,

Gabriel

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Zachary Amsden]

Gabriel Barazer wrote:
> Hi,
>
> After upgrading kernel to 2.6.22 on a Vmware workstation guest version 
> 5.5 and 6 , the kernel decompression stage ("Decompressing Linux...") 
> is hanging for a very long time (~5 minutes) before finally  
> succeeding (displaying "done.\nBooting the kernel.\n"). During this 
> time, the VM process is eating all the CPU time during the 
> decompression, like an infinite loop. 

LKML is not the right place for this question.  You are running on Intel 
hardware?

Bring the discussion over to http://www.vmware.com/community forums

Zach

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Zachary Amsden]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

Gabriel Barazer wrote:
> Hi,
>
> After upgrading kernel to 2.6.22 on a Vmware workstation guest version 
> 5.5 and 6 , the kernel decompression stage ("Decompressing Linux...") 
> is hanging for a very long time (~5 minutes) before finally  
> succeeding (displaying "done.\nBooting the kernel.\n"). During this 
> time, the VM process is eating all the CPU time during the 
> decompression, like an infinite loop.
> Between these 2 strings is the gunzip() function at 
> boot/compressed/misc.c which does the real job, and the problem seemed 
> to appear since commit 1ab60e0f72f71ec54831e525a3e1154f1c092408. 
> (2.6.22-rc1 hangs, 2.6.21.6 works). The problem occurs with or without 
> CONFIG_RELOCATABLE enabled.
>
> What are the possible solutions to confirm where the problem is coming 
> from ?

Since I was just involved in the boot decompressor for another bug, I 
took a look at this.  2.6.22 switches it to be 64-bit code.  VT is very 
picky about what state it can run in.  Not using VT on Intel 64-bit 
hardware cripples performance, running at far below normal speed, and 
taking minutes to decompress the kernel, which is nearly instantaneous 
otherwise.

To get back into VT in this case, not only do we need to load FS and GS, 
we also need to setup an initial LDT and task.  Can you try the attached 
patch and see that it does the right thing?

I've also cc'd the KVM developers, as the same problem will affect them, 
and hopefully the same patch will fix it.

Thanks, Zach

Zach

[-- Attachment #2: boot-decompress-vt-fix.patch --]
[-- Type: text/x-patch, Size: 1206 bytes --]

VT is very picky about when it can enter execution.
Get all segments setup and get LDT and TR into valid state to allow
VT execution under VMware and KVM (untested).

This makes the boot decompression run under VT, which makes it several
orders of magnitude faster on 64-bit Intel hardware.

Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.

Signed-off-by: Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>


===================================================================
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compressed/head.S
@@ -195,6 +195,11 @@
 	movl	%eax, %ds
 	movl	%eax, %es
 	movl	%eax, %ss
+	movl	%eax, %fs
+	movl	%eax, %gs
+	lldt	%ax
+	movl    $0x20, %eax
+	ltr	%ax
 
 	/* Compute the decompressed kernel start address.  It is where
 	 * we were loaded at aligned to a 2M boundary. %rbp contains the
@@ -295,6 +300,8 @@
 	.quad	0x0000000000000000	/* NULL descriptor */
 	.quad	0x00af9a000000ffff	/* __KERNEL_CS */
 	.quad	0x00cf92000000ffff	/* __KERNEL_DS */
+	.quad	0x0080890000000000	/* TS descriptor */
+	.quad   0x0000000000000000	/* TS continued */
 gdt_end:
 	.bss
 /* Stack for uncompression */

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Zachary Amsden]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

Gabriel Barazer wrote:
> Hi,
>
> After upgrading kernel to 2.6.22 on a Vmware workstation guest version 
> 5.5 and 6 , the kernel decompression stage ("Decompressing Linux...") 
> is hanging for a very long time (~5 minutes) before finally  
> succeeding (displaying "done.\nBooting the kernel.\n"). During this 
> time, the VM process is eating all the CPU time during the 
> decompression, like an infinite loop.
> Between these 2 strings is the gunzip() function at 
> boot/compressed/misc.c which does the real job, and the problem seemed 
> to appear since commit 1ab60e0f72f71ec54831e525a3e1154f1c092408. 
> (2.6.22-rc1 hangs, 2.6.21.6 works). The problem occurs with or without 
> CONFIG_RELOCATABLE enabled.
>
> What are the possible solutions to confirm where the problem is coming 
> from ?

Since I was just involved in the boot decompressor for another bug, I 
took a look at this.  2.6.22 switches it to be 64-bit code.  VT is very 
picky about what state it can run in.  Not using VT on Intel 64-bit 
hardware cripples performance, running at far below normal speed, and 
taking minutes to decompress the kernel, which is nearly instantaneous 
otherwise.

To get back into VT in this case, not only do we need to load FS and GS, 
we also need to setup an initial LDT and task.  Can you try the attached 
patch and see that it does the right thing?

I've also cc'd the KVM developers, as the same problem will affect them, 
and hopefully the same patch will fix it.

Thanks, Zach

Zach

[-- Attachment #2: boot-decompress-vt-fix.patch --]
[-- Type: text/x-patch, Size: 1177 bytes --]

VT is very picky about when it can enter execution.
Get all segments setup and get LDT and TR into valid state to allow
VT execution under VMware and KVM (untested).

This makes the boot decompression run under VT, which makes it several
orders of magnitude faster on 64-bit Intel hardware.

Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.

Signed-off-by: Zachary Amsden <zach@vmware.com>


===================================================================
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compressed/head.S
@@ -195,6 +195,11 @@
 	movl	%eax, %ds
 	movl	%eax, %es
 	movl	%eax, %ss
+	movl	%eax, %fs
+	movl	%eax, %gs
+	lldt	%ax
+	movl    $0x20, %eax
+	ltr	%ax
 
 	/* Compute the decompressed kernel start address.  It is where
 	 * we were loaded at aligned to a 2M boundary. %rbp contains the
@@ -295,6 +300,8 @@
 	.quad	0x0000000000000000	/* NULL descriptor */
 	.quad	0x00af9a000000ffff	/* __KERNEL_CS */
 	.quad	0x00cf92000000ffff	/* __KERNEL_DS */
+	.quad	0x0080890000000000	/* TS descriptor */
+	.quad   0x0000000000000000	/* TS continued */
 gdt_end:
 	.bss
 /* Stack for uncompression */

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Gabriel Barazer]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On 08/04/2007 6:23:00 PM +0200, Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> wrote:
> Gabriel Barazer wrote:
>> Hi,
>>
>> After upgrading kernel to 2.6.22 on a Vmware workstation guest version 
>> 5.5 and 6 , the kernel decompression stage ("Decompressing Linux...") 
>> is hanging for a very long time (~5 minutes) before finally  
>> succeeding (displaying "done.\nBooting the kernel.\n"). During this 
>> time, the VM process is eating all the CPU time during the 
>> decompression, like an infinite loop.
>> Between these 2 strings is the gunzip() function at 
>> boot/compressed/misc.c which does the real job, and the problem seemed 
>> to appear since commit 1ab60e0f72f71ec54831e525a3e1154f1c092408. 
>> (2.6.22-rc1 hangs, 2.6.21.6 works). The problem occurs with or without 
>> CONFIG_RELOCATABLE enabled.
>>
>> What are the possible solutions to confirm where the problem is coming 
>> from ?
> 
> Since I was just involved in the boot decompressor for another bug, I 
> took a look at this.  2.6.22 switches it to be 64-bit code.  VT is very 
> picky about what state it can run in.  Not using VT on Intel 64-bit 
> hardware cripples performance, running at far below normal speed, and 
> taking minutes to decompress the kernel, which is nearly instantaneous 
> otherwise.
> 
> To get back into VT in this case, not only do we need to load FS and GS, 
> we also need to setup an initial LDT and task.  Can you try the attached 
> patch and see that it does the right thing?

It Works (tm) ! Tried compiling with and without the patch, with exactly 
the same config, just to be sure. Decompressing the kernel is now 
lightning fast.

Thanks !

> I've also cc'd the KVM developers, as the same problem will affect them, 
> and hopefully the same patch will fix it.

[-- Attachment #2: boot-decompress-vt-fix.patch --]
[-- Type: text/x-patch, Size: 1206 bytes --]

VT is very picky about when it can enter execution.
Get all segments setup and get LDT and TR into valid state to allow
VT execution under VMware and KVM (untested).

This makes the boot decompression run under VT, which makes it several
orders of magnitude faster on 64-bit Intel hardware.

Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.

Signed-off-by: Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>


===================================================================
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compressed/head.S
@@ -195,6 +195,11 @@
 	movl	%eax, %ds
 	movl	%eax, %es
 	movl	%eax, %ss
+	movl	%eax, %fs
+	movl	%eax, %gs
+	lldt	%ax
+	movl    $0x20, %eax
+	ltr	%ax
 
 	/* Compute the decompressed kernel start address.  It is where
 	 * we were loaded at aligned to a 2M boundary. %rbp contains the
@@ -295,6 +300,8 @@
 	.quad	0x0000000000000000	/* NULL descriptor */
 	.quad	0x00af9a000000ffff	/* __KERNEL_CS */
 	.quad	0x00cf92000000ffff	/* __KERNEL_DS */
+	.quad	0x0080890000000000	/* TS descriptor */
+	.quad   0x0000000000000000	/* TS continued */
 gdt_end:
 	.bss
 /* Stack for uncompression */

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Gabriel Barazer]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On 08/04/2007 6:23:00 PM +0200, Zachary Amsden <zach@vmware.com> wrote:
> Gabriel Barazer wrote:
>> Hi,
>>
>> After upgrading kernel to 2.6.22 on a Vmware workstation guest version 
>> 5.5 and 6 , the kernel decompression stage ("Decompressing Linux...") 
>> is hanging for a very long time (~5 minutes) before finally  
>> succeeding (displaying "done.\nBooting the kernel.\n"). During this 
>> time, the VM process is eating all the CPU time during the 
>> decompression, like an infinite loop.
>> Between these 2 strings is the gunzip() function at 
>> boot/compressed/misc.c which does the real job, and the problem seemed 
>> to appear since commit 1ab60e0f72f71ec54831e525a3e1154f1c092408. 
>> (2.6.22-rc1 hangs, 2.6.21.6 works). The problem occurs with or without 
>> CONFIG_RELOCATABLE enabled.
>>
>> What are the possible solutions to confirm where the problem is coming 
>> from ?
> 
> Since I was just involved in the boot decompressor for another bug, I 
> took a look at this.  2.6.22 switches it to be 64-bit code.  VT is very 
> picky about what state it can run in.  Not using VT on Intel 64-bit 
> hardware cripples performance, running at far below normal speed, and 
> taking minutes to decompress the kernel, which is nearly instantaneous 
> otherwise.
> 
> To get back into VT in this case, not only do we need to load FS and GS, 
> we also need to setup an initial LDT and task.  Can you try the attached 
> patch and see that it does the right thing?

It Works (tm) ! Tried compiling with and without the patch, with exactly 
the same config, just to be sure. Decompressing the kernel is now 
lightning fast.

Thanks !

> I've also cc'd the KVM developers, as the same problem will affect them, 
> and hopefully the same patch will fix it.

[-- Attachment #2: boot-decompress-vt-fix.patch --]
[-- Type: text/x-patch, Size: 1177 bytes --]

VT is very picky about when it can enter execution.
Get all segments setup and get LDT and TR into valid state to allow
VT execution under VMware and KVM (untested).

This makes the boot decompression run under VT, which makes it several
orders of magnitude faster on 64-bit Intel hardware.

Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.

Signed-off-by: Zachary Amsden <zach@vmware.com>


===================================================================
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compressed/head.S
@@ -195,6 +195,11 @@
 	movl	%eax, %ds
 	movl	%eax, %es
 	movl	%eax, %ss
+	movl	%eax, %fs
+	movl	%eax, %gs
+	lldt	%ax
+	movl    $0x20, %eax
+	ltr	%ax
 
 	/* Compute the decompressed kernel start address.  It is where
 	 * we were loaded at aligned to a 2M boundary. %rbp contains the
@@ -295,6 +300,8 @@
 	.quad	0x0000000000000000	/* NULL descriptor */
 	.quad	0x00af9a000000ffff	/* __KERNEL_CS */
 	.quad	0x00cf92000000ffff	/* __KERNEL_DS */
+	.quad	0x0080890000000000	/* TS descriptor */
+	.quad   0x0000000000000000	/* TS continued */
 gdt_end:
 	.bss
 /* Stack for uncompression */

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Avi Kivity]

Zachary Amsden wrote:
>
> Since I was just involved in the boot decompressor for another bug, I 
> took a look at this.  2.6.22 switches it to be 64-bit code.  VT is 
> very picky about what state it can run in.  Not using VT on Intel 
> 64-bit hardware cripples performance, running at far below normal 
> speed, and taking minutes to decompress the kernel, which is nearly 
> instantaneous otherwise.
>
> To get back into VT in this case, not only do we need to load FS and 
> GS, we also need to setup an initial LDT and task.  Can you try the 
> attached patch and see that it does the right thing?
>
> I've also cc'd the KVM developers, as the same problem will affect 
> them, and hopefully the same patch will fix it.
>

We haven't seen any issue with the 2.6.22 boot decompressor.  Which of 
the four (fs, gs, ldt, or tr) were proving problematic and why?



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Avi Kivity]

Zachary Amsden wrote:
>
> Since I was just involved in the boot decompressor for another bug, I 
> took a look at this.  2.6.22 switches it to be 64-bit code.  VT is 
> very picky about what state it can run in.  Not using VT on Intel 
> 64-bit hardware cripples performance, running at far below normal 
> speed, and taking minutes to decompress the kernel, which is nearly 
> instantaneous otherwise.
>
> To get back into VT in this case, not only do we need to load FS and 
> GS, we also need to setup an initial LDT and task.  Can you try the 
> attached patch and see that it does the right thing?
>
> I've also cc'd the KVM developers, as the same problem will affect 
> them, and hopefully the same patch will fix it.
>

We haven't seen any issue with the 2.6.22 boot decompressor.  Which of 
the four (fs, gs, ldt, or tr) were proving problematic and why?

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Zachary Amsden]

Avi Kivity wrote:
>
> We haven't seen any issue with the 2.6.22 boot decompressor.  Which of 
> the four (fs, gs, ldt, or tr) were proving problematic and why?

It was tr that was affecting Workstation, since we boot through normal 
BIOS path, and only a 16-bit task was loaded at this point.

Just to make the state comprehensive, I opted to reload everything.

Zach

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Zachary Amsden]

Avi Kivity wrote:
>
> We haven't seen any issue with the 2.6.22 boot decompressor.  Which of 
> the four (fs, gs, ldt, or tr) were proving problematic and why?

It was tr that was affecting Workstation, since we boot through normal 
BIOS path, and only a 16-bit task was loaded at this point.

Just to make the state comprehensive, I opted to reload everything.

Zach

Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware

[Avi Kivity]

Zachary Amsden wrote:
> Avi Kivity wrote:
>>
>> We haven't seen any issue with the 2.6.22 boot decompressor.  Which 
>> of the four (fs, gs, ldt, or tr) were proving problematic and why?
>
> It was tr that was affecting Workstation, since we boot through normal 
> BIOS path, and only a 16-bit task was loaded at this point.
>

Ah.  Maybe we didn't have an exit while we were in long mode with the 
16-bit tss, so VT didn't notice the illegal combination.