WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [rfc] [patch] more 'long' in the hypervisor interface

* Hollis Blanchard (hollisb@xxxxxxxxxx) wrote:
> We discussed a bit on IRC (developers are welcome to join OFTC #xen),
> but to recap for the list...
> 
> PPC will have
>       typedef uint64_t xen_ulong_t;
> That means that the fields in memory.h will keep the same
> size/alignment, whether compiled 32- or 64-bit. This is the way the
> interface should have been designed in the first place, but we're locked
> into the current ABI on x86. However, since PPC has no current users, we
> can define the ABI correctly from the start.

I see.  I think it would be nice to work on the ABI such that it makes
sense for the future 32/64 mixed modes.  So I guess I actually agree
with your legacy typedef name ;-)

One issue is that 32-bit userspace effectively has direct access to
64-bit hypercall interface.  This can be handled in the 64-bit kernel by
doing compat translation, by having 32-bit compat hypercall interface
and jumping to right spot on hypercall page, or by having fixed size
structure.  It's not clear to me the value of effectively exposing the
ABI all the way to userspace.

What is the current plan for 32-bit kernel on 64-bit hv?  In this case
a 32-bit compat hypercall page might be useful, or having fixed size
structure.

My concern is that we'll never make a clean break if we slowly cobble up
the interface with more hacks.  Maybe a forward looking compat interface
would be a good breaking point.

thanks,
-chris

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