The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <ak@suse.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	patches@x86-64.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH for 2.6.19] [3/9] x86_64: shorten the x86_64 boot setup GDT to what the comment says
Date: Wed, 15 Nov 2006 11:00:30 +0100	[thread overview]
Message-ID: <20061115100030.GA5753@elte.hu> (raw)
In-Reply-To: <20061114160853.9F16213C98@wotan.suse.de>


> From: Steven Rostedt <rostedt@goodmis.org>
> 
> 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.
> 
> AK: changed to compute true gdt size in assembler, fixed comment
> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Andi Kleen <ak@suse.de>

Acked-by: Ingo Molnar <mingo@elte.hu>

note, it seems to me that i386 had this fix years ago already.

	Ingo

  reply	other threads:[~2006-11-15 10:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-14 16:08 [PATCH for 2.6.19] [1/9] x86_64: Fix partial page check to ensure unusable memory is not being marked usable Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [2/9] x86_64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [3/9] x86_64: shorten the x86_64 boot setup GDT to what the comment says Andi Kleen
2006-11-15 10:00   ` Ingo Molnar [this message]
2006-11-14 16:08 ` [PATCH for 2.6.19] [4/9] x86_64: Handle reserve_bootmem_generic beyond end_pfn Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [5/9] x86_64: setup saved_max_pfn correctly (kdump) Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [6/9] x86_64: Update MMCONFIG resource insertion to check against e820 map Andi Kleen
2006-11-14 18:38   ` Andi Kleen
2006-11-14 18:47     ` Aaron Durbin
2006-11-14 18:58       ` Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [7/9] x86: Add acpi_user_timer_override option for Asus boards Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [8/9] x86_64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled Andi Kleen
2006-11-14 16:08 ` [PATCH for 2.6.19] [9/9] x86_64: Fix race in exit_idle Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061115100030.GA5753@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@x86-64.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox