WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: "Barry Silverman": Setting GDT entries for Thread Lo

To: Zachary Amsden <zamsden@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: "Barry Silverman": Setting GDT entries for Thread Local Storage
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 10 Feb 2004 18:10:50 +0000
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Delivery-date: Tue, 10 Feb 2004 18:18:06 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 10 Feb 2004 09:49:19 PST." <4029199F.9060008@xxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> I don't want to throw a monkeywrench in your plans, but another 
> potential trouble spot is the x86 vsyscall interface in 2.6.  The 
> vsyscall region sits at the top of the virtual address space, and could 
> conflict with the Xen mapping.  You may have to consider remapping Xen 
> to another memory region, but I'm not sure where there may be other 
> trouble areas with Windows domains (map?).  At some point in the 
> forseeable future, it might no longer be possible to locate Xen at an OS 
> neutral location, so perhaps it is worth considering the remapping 
> problem now.

The vsyscall interface happens to sit at the top of virtual memory in
native Linux, I think mainly because the vsyscall page is allocated
using the Linux 'fixmap' mechanism.

However, the address of the vsyscall interface is passed to
applications as part of the ELF-loading protocol. It should therefore
be possible to map the vsyscall stubs to a different virtual address
in Xenolinux (Fingers crossed!).

I hope we don't have to go down a 'map Xen to guest-specific location'
kind of route. I think that position-independent code in x86 is likely
to perform below-par (no PC-relative addressing; allocating a base
register is painful on a register-starved architecture).

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel