From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: Re: "Barry Silverman": Setting GDT entries for Thread Local Storage Date: Tue, 10 Feb 2004 11:33:16 -0800 Sender: xen-devel-admin@lists.sourceforge.net Message-ID: <402931FC.6000106@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Keir Fraser Cc: xen-devel@lists.sourceforge.net, Ian Pratt List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: >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 think that might work, but it seems somewhat unnecessary. Does Xen use the very top part of VM space for any special purpose - e.g. stack? Why not just make Xen itself a kernel fixmap entry to avoid collisions? >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). > > Not to mention having to deal with relocatable pointers across different domains! Ugh. Zachary Amsden zamsden@cisco.com ------------------------------------------------------- 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