[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070809124133.D559014F3B@wotan.suse.de>
Date: Thu, 9 Aug 2007 14:41:33 +0200 (CEST)
From: Andi Kleen <ak@...e.de>
To: zach@...are.com, patches@...-64.org, linux-kernel@...r.kernel.org
Subject: [PATCH] [6/12] x86_64: Early segment setup for VT
From: Zachary Amsden <zach@...are.com>
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@...are.com>
Signed-off-by: Andi Kleen <ak@...e.de>
---
arch/x86_64/boot/compressed/head.S | 7 +++++++
1 file changed, 7 insertions(+)
Index: linux/arch/x86_64/boot/compressed/head.S
===================================================================
--- linux.orig/arch/x86_64/boot/compressed/head.S
+++ linux/arch/x86_64/boot/compressed/head.S
@@ -195,6 +195,11 @@ ENTRY(startup_64)
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 @@ gdt:
.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 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists