Mailing List Archive

[PATCH] shorten the x86_64 boot setup GDT to what the comment says
Andi,

Stephen Tweedie, Herbert Xu, and myself have been struggling with a very
nasty bug in Xen. But it also pointed out a small bug in the x86_64
kernel boot setup.

The GDT limit being setup by the initial bzImage code when entering into
protected mode is way too big. The comment by the code states that the
size of the GDT is 2048, but the actual size being set up is much bigger
(32768). This happens simply because of one extra '0'.

Instead of setting up a 0x800 size, 0x8000 is set up. On bare metal this
is fine because the CPU wont load any segments unless they are
explicitly used. But unfortunately, this breaks Xen on vmx FV, since it
(for now) blindly loads all the segments into the VMCS if they are less
than the gdt limit. Since the real mode segments are around 0x3000, we are
getting junk into the VMCS and that later causes an exception.

Stephen Tweedie has written up a patch to fix the Xen side and will be
submitting that to those folks. But that doesn't excuse the GDT limit
being a magnitude too big.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux-2.6.19-rc2/arch/x86_64/boot/setup.S
===================================================================
--- linux-2.6.19-rc2.orig/arch/x86_64/boot/setup.S 2006-11-08 21:37:58.000000000 -0500
+++ linux-2.6.19-rc2/arch/x86_64/boot/setup.S 2006-11-08 21:38:16.000000000 -0500
@@ -840,7 +840,7 @@ idt_48:
.word 0 # idt limit = 0
.word 0, 0 # idt base = 0L
gdt_48:
- .word 0x8000 # gdt limit=2048,
+ .word 0x800 # gdt limit=2048,
# 256 GDT entries

.word 0, 0 # gdt base (filled in later)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH] shorten the x86_64 boot setup GDT to what the comment says [ In reply to ]
On Thu, 9 Nov 2006, Alexander van Heukelum wrote:

> > gdt_48:
> > - .word 0x8000 # gdt limit=2048,
> > + .word 0x800 # gdt limit=2048,
> > # 256 GDT entries
> >
> > .word 0, 0 # gdt base (filled in later)
>
> The limit should be the offset of the last byte of the gdt table. So
> I think what was meant was really 0x7ff. Comparing this code with the
> i386-version, why does x86_64 need 256 entries here, while i386 is happy
> with just the code-segment and data-segment descriptors?
>


Hmm, Andi,

Should this be more like what is done in x86? Although this isn't a major
bug or anything, would it be cleaner. For example doing:

@@ -836,11 +836,15 @@ gdt:
.word 0x9200 # data read/write
.word 0x00CF # granularity = 4096, 386
# (+5th nibble of limit)
+gdt_end:
+ .align 4
+
+ .word 0 # alignment byte
idt_48:
.word 0 # idt limit = 0
.word 0, 0 # idt base = 0L
gdt_48:
- .word 0x8000 # gdt limit=2048,
+ .word gdt_end - gdt - 1 # gdt limit=2048,
# 256 GDT entries

.word 0, 0 # gdt base (filled in

instead?

If so, I can send you another patch that does this. Will need to test it
first.

-- Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH] shorten the x86_64 boot setup GDT to what the comment says [ In reply to ]
On Thu, Nov 09, 2006 at 10:18:53AM -0500, Steven Rostedt wrote:
> Hmm, Andi,
>
> Should this be more like what is done in x86? Although this isn't a major
> bug or anything, would it be cleaner. For example doing:
>
> @@ -836,11 +836,15 @@ gdt:
> .word 0x9200 # data read/write
> .word 0x00CF # granularity = 4096, 386
> # (+5th nibble of limit)
> +gdt_end:
> + .align 4
> +
> + .word 0 # alignment byte
> idt_48:
> .word 0 # idt limit = 0
> .word 0, 0 # idt base = 0L
> gdt_48:
> - .word 0x8000 # gdt limit=2048,
> + .word gdt_end - gdt - 1 # gdt limit=2048,
> # 256 GDT entries
>
> .word 0, 0 # gdt base (filled in
>
> instead?

Hi!

Maybe you should consider 16-byte aligning the gdt table too, like
i386 does? It doesn't hurt, and as per the comment in the i386-file
"16 byte aligment is recommended by intel."

Greetings,
Alexander van Heukelum

> If so, I can send you another patch that does this. Will need to test it
> first.
>
> -- Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel