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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> > 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel