Xen devel - Feb 2006 - RE: Re: [Xen-changelog] Indirect hypercalls through ahypercall transfer page.

> > The hypercall transfer page is just one of several new 
> feature flags 
> > that should enable us to have a single xen-ified kernel that is 
> > capable of running on bare metal, on pae and non-pae 
> hypervisors, 64b
> 
> A 32-bit kernel running on a 64-bit xen, for example? So in 
> this case xen fills the page with 32-bit hcalls?
Our current priority developing xen feature flags has been to enable
xenified kernels to run on bare metal and to allow non-PAE kernels on a
PAE hypervisor, but 32 on 64 is certainly something it would be good to
support too.

The key feature flag we''re still missing is the ability for the guest
kernel to query the size of the ''hypervisor hole'' at boot
time, and then
adjust its VM layout appropriately. Conceptually, this is quite simple
for Linux -- just turn HYPERVISOR_VIRTSTART into a variable.
Unfortunately, things are a little more complicated: right at the top of
the kernel''s virtual address space is the fixaddr region. The vsyscall
page lives within the fixaddr region, and its virtual address needs to
be known at *compile* time as it gets built into various elf objects.

A number of options are aviable to fix this 1) provide either kernel or
domain builder support for relocating the syscall page (sounds hard); 2)
move the vsyscall page out of fixmap and put it somewhere toward the
bottom of the virtual address space; 3) move the vsyscall page out of
fixmap and put it just below the kernel address space (i.e. top of user
space). The latter is the currently favoured option, as recommended by
Andi (it''s also used by the x86_64 ia32 compat layer). I''m
hoping we can
get this in before the SLES10 xen kernel gets finalized.


Ian





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

Ian Pratt wrote:
> The vsyscall
> page lives within the fixaddr region, and its virtual address needs to
> be known at *compile* time as it gets built into various elf objects.
That''s not necessarily the case.

The FC x86 kernel has random vdso address support.  I don''t know why
this isn''t also enabled for x86-64 but there is no real reason for
that.
   These are, after all, DSOs which need little fixup for a new location.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖



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

Ulrich Drepper wrote:
> I don''t know why
> this isn''t also enabled for x86-64 but there is no real reason for
that.
Actually, I remember.  It''s Andi insistance on this stupid vsyscall
interface with fixed addresses.  This is absolutely unnecessary.  vdsos
are so much nicer to handle, need no special code.  If somebody would
finally be able to replace the vsyscall stuff x86-64 currently uses with
a vdso implementation (passing up the address in the auxiliary vector)
all would be nice and easy.  x86 and ppc already use the vdso, it''s not
an unproven concept.  ppc even uses it in a way which would be needed to
implement the fast gettimeofday etc.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖



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