segmentation and Xen

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

segmentation and Xen

jonmccune
Hello,

We noticed a difference in the kernel and user space code and data
segment descriptor entries in the GDTs for Xen and XenoLinux.  It does
not appear that the Xen GDT totally supplants the Linux GDT, as the
Linux GDT has its limit changed (in the descriptor, but not the
comments) appropriately to make room for Xen in the upper 64 MB.  The
difference is in the "Accessed" bit of the "Type" field, as defined in
Chapter 4, Volume 3, of the Intel manuals.  Can you help us to
understand why the Access bit is set in the Linux kernel code but not in
the Xen code?

More generally, how do the GDTs defined in head.S and x86_32.S
interact?  It seems problematic that Xen defines a GDT for guest OSes,
but guest OSes are allowed to retain a GDT of their own.

Thanks,
-Jon


linux-2.6.12-xenU/arch/xen/i386/kernel/head.S

#ifdef CONFIG_X86_PAE
        .quad 0x00cfbb00000067ff        /* 0x60 kernel 4GB code at 0x00000000 */
        .quad 0x00cfb300000067ff        /* 0x68 kernel 4GB data at 0x00000000 */
        .quad 0x00cffb00000067ff        /* 0x73 user 4GB code at 0x00000000 */
        .quad 0x00cff300000067ff        /* 0x7b user 4GB data at 0x00000000 */
#else
        .quad 0x00cfbb000000c3ff        /* 0x60 kernel 4GB code at 0x00000000 */
        .quad 0x00cfb3000000c3ff        /* 0x68 kernel 4GB data at 0x00000000 */
        .quad 0x00cffb000000c3ff        /* 0x73 user 4GB code at 0x00000000 */
        .quad 0x00cff3000000c3ff        /* 0x7b user 4GB data at 0x00000000 */
#endif

xen/arch/x86/boot/x86_32.S

#ifdef CONFIG_X86_PAE
        .quad 0x00cfba00000067ff
        .quad 0x00cfb200000067ff
        .quad 0x00cffa00000067ff
        .quad 0x00cff200000067ff
#else
        .quad 0x00cfba000000c3ff     /* 0xe019 ring 1 3.95GB code at 0x0 */
        .quad 0x00cfb2000000c3ff     /* 0xe021 ring 1 3.95GB data at 0x0 */
        .quad 0x00cffa000000c3ff     /* 0xe02b ring 3 3.95GB code at 0x0 */
        .quad 0x00cff2000000c3ff     /* 0xe033 ring 3 3.95GB data at 0x0 */
#endif


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: segmentation and Xen

Keir Fraser

On 14 Oct 2005, at 18:00, Jonathan M. McCune wrote:

> We noticed a difference in the kernel and user space code and data
> segment descriptor entries in the GDTs for Xen and XenoLinux.  It does
> not appear that the Xen GDT totally supplants the Linux GDT, as the
> Linux GDT has its limit changed (in the descriptor, but not the
> comments) appropriately to make room for Xen in the upper 64 MB.  The
> difference is in the "Accessed" bit of the "Type" field, as defined in
> Chapter 4, Volume 3, of the Intel manuals.  Can you help us to
> understand why the Access bit is set in the Linux kernel code but not
> in the Xen code?

Noone uses the accessed bit for anything, so it doesn't matter how it
is set. I guess if you set it in the table definition then the CPU
doesn't need to set the accessed bit the first time the segment is
loaded, but that really doesn't matter either way...

> More generally, how do the GDTs defined in head.S and x86_32.S
> interact?  It seems problematic that Xen defines a GDT for guest OSes,
> but guest OSes are allowed to retain a GDT of their own.

Note that the Xen GDT (defined in x86_32.S) is not based at offset
zero! Xen reserves the final eighth of the GDT space. The first
seven-eighths are available for guests to define.

  -- Keir


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel