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

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

> You would instead propose a compatibility layer in Xen? So 
> when a hypercall from a 32-bit guest arrives at a 64-bit 
> hypervisor, Xen code converts the 32-bit structure into a 
> 64-bit one and passes that pointer on to the rest of Xen? And 
> then for return values you'd convert the other way. Hmm, and 
> of course you wouldn't be able to pass 64-bit addresses back, 
> such as via dom0_tbufcontrol_t.

The dom0 API is a xen <-> tools API. That's *not* part of the gen guest
API.

Needing 64 bit *capable* tools for a 64 bit hypevisor is clearly a
requirement. [The fact that Power wants to implement 64 bit capable
tools as a 32 bit user space binary is totally orthogonal (and some
might say slightly perverse)]  
 
> As mentioned previously, this is the approach Linux uses 
> (linux/fs/compat_ioctl.c), and it seems less than ideal to 
> me. Since we have the ability to fix it now (i.e. make the 
> 32-bit and 64-bit ABI identical), shouldn't we do that rather 
> than this copying/munging layer?

Although I wouldn't object to using u64 everywhere in the tools (dom0)
API, I most certainly would object to using it everywhere in the 32 bit
x86 guest API as it would hurt performance and waste memory.
*Definitely*.

Just changing the tools API to all u64 seems pointless, as if you're
using a 64 bit hypervisor it seems perfectly reasonable to insist on
using 64 bit tools -- every other system binary on your 64 bit
redhat/suse install is going to be specially compiled for 64 bit, so why
not yout hypervisor tools! 

If we're going to make a change at all, switching to using ureg (or
similar) rather than 'long' is the thing to do to. This makes the job of
implementing some future compat layer very slightly easier, and helps
the Power guys do their funky 64-bit-tools-as-a-32-bit-binary thing. [*]
 
Ian

[*] implementing a hypercall compat layer is trivial compared to other
overheads you'd have (like shadow page tables). 







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