[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 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.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.