Re: [GIT PULL] x86 setup: work around bug in Xen HVM

["H. Peter Anvin" <hpa@zytor.com>]

Christoph Hellwig wrote:
> On Tue, Sep 04, 2007 at 09:55:45AM -0700, H. Peter Anvin wrote:
> >     
> >     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 Xen bug but given that there is a one-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.
>
> > -	struct gdt_ptr gdt;
> > +	static struct gdt_ptr gdt;
>
> It might make sense to add your above commit message to the code as a comment.

Good point; I have amended the commit with a brief comment:

diff --git a/arch/i386/boot/pm.c b/arch/i386/boot/pm.c
index 6be9ca8..09fb342 100644
--- a/arch/i386/boot/pm.c
+++ b/arch/i386/boot/pm.c
@@ -122,7 +122,11 @@ static void setup_gdt(void)
                /* DS: data, read/write, 4 GB, base 0 */
                [GDT_ENTRY_BOOT_DS] = GDT_ENTRY(0xc093, 0, 0xfffff),
        };
-       struct gdt_ptr gdt;
+       /* Xen HVM incorrectly stores a pointer to the gdt_ptr, instead
+          of the gdt_ptr contents.  Thus, make it static so it will
+          stay in memory, at least long enough that we switch to the
+          proper kernel GDT. */
+       static struct gdt_ptr gdt;

        gdt.len = sizeof(boot_gdt)-1;
        gdt.ptr = (u32)&boot_gdt + (ds() << 4);

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/