RE: [Xen-devel] 32/64-bit hypercall interface

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

> start_info_t: tools, kernel
> xen_parameters_info_t: tools, hypervisor
> gnttab_setup_table_t: kernel, hypervisor
> gnttab_transfer_t: kernel, hypervisor
> struct xen_memory_reservation: tools, kernel, hypervisor 
> struct t_rec: tools, hypervisor struct t_buf: tools, hypervisor
> 
> (This was just a quick grep for "long" in xen/include/public.)
> 
> The tools/hypervisor interface seems to be the most important 
> at the moment. I don't know if anybody has plans to do 32-bit 
> kernel on a 64-bit hypervisor... 
> but why not enable it while we're in there?

There's rather more to running a 32 bit x86 xen guest on a 64 bit
hypervisor then just worrying about the header files. I wouldn't rule
out ever doing it, but there'll be a significant performance cost (e.g.
it will require shadow pagetables) and a significant amount of work.

The hypervisor to guest interface is obviously performance critical, and
just changing everything into a 64 bit quantity certainly would not make
sense from a memory usage, cache footprint and instruction count point
of view. Looking through the public guest interface, the current use of
'long' to get 32 bit quantities on x86_32 and 64 on x86_64 actually
makes good sense.

However, I don't think we should be using 'long' directly in public
headers as it makes it harder to override. For example, if we ever
support 32 bit guests on a 64 bit hypervisor we may want to use multiple
compilation to build a compatibility layer or such like. We should
probably typedef something like 'ureg' that we could override as
appropriate. This would also enable the Power folks to build a 32 bit
binary tools for a 64 bit hypervisor.

[I think I favour using a single typedef like 'ureg' rather than coming
up coming up with different names for all of the different uses of
'long' as the latter seems faorly pointless]

However, since we're not actually changing the size of any types, this
change isn't essential to rush through before 3.0, though it might be
nice as it should be very low risk.

Ian

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