From: "Jonathan M. McCune" <jonmccune@cmu.edu>
To: xen-devel@lists.xensource.com
Cc: Arvind Seshadri <arvinds@cs.cmu.edu>, Bryan Parno <parno@cmu.edu>
Subject: segmentation and Xen
Date: Fri, 14 Oct 2005 13:00:48 -0400 [thread overview]
Message-ID: <434FE440.6080904@cmu.edu> (raw)
[-- 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
next reply other threads:[~2005-10-14 17:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-14 17:00 Jonathan M. McCune [this message]
2005-10-15 7:50 ` segmentation and Xen Keir Fraser
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=434FE440.6080904@cmu.edu \
--to=jonmccune@cmu.edu \
--cc=arvinds@cs.cmu.edu \
--cc=parno@cmu.edu \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.