segmentation and Xen

segmentation and Xen

[Jonathan M. McCune]

[-- Attachment #1.1: Type: text/plain, Size: 2010 bytes --]

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


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3170 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

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