[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 6/7, RFC] x86_64: basic changes for supporting compatibility mode guest



>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 23.08.06 12:36 >>>
>On 23/8/06 11:17 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> Then libxc/xc_linux_build.c (after appropriate adjustment) wouldn't have
>> a way to communicate these for a new domain. If extending the structure
>> isn't possible at all, then we'll either have to make event_callback_eip and
>> failsafe_callback_eip unions (permitting a selector:offset pair) or make
>> syscall_callback_eip a union (permitting storing the selectors). I'd favor
>> the second option as that field is entirely useless as long as x86_32
>> doesn't support syscall (which doesn't make sense as it would make
>> things slower rather than speeding them up) - that way one doesn't have
>> to be careful to not access the other two full 64bit *_callback_eip
>> fields.
>
>If we do 32-bit dom0 kernel then the tools will pick up the 32-bit version
>of that structure. So this is only an issue for userspace if we want 64-bit
>dom0 to be able to build 32-bit domU's. I suppose this would be nice to
>have.

Of course. From NetWare's perspective it is even more than just 'nice to
have'.

>Obvious thing to do is suffix all the structs and defns in arch-x86_foo.h
>with _32 or _64 as appropriate. Then, at the end of the header, we define
>the non-suffixed versions only if defined(__i386__) or __defined__(x86_64)
>(as appropriate).
>
>This avoids breaking the domU API unnecessarily but allows those who want to
>make the distinction to use the suffixed versions.

Implying that you would add an extra hypercall sub-functions that you could
pass in a non-native structures? Doesn't seem too nice to me.
Also, all the public headers will anyway need to be converted to compatibility
ones (the next thing I intend to do actually), so converting arch-x86_32.h
will come as a by-product, and handling the compatibility structure will be
purely a job of the compatibility hypercalls, except for the need to add a
compatibility flag to the domain creation request and to handle dual-purpose
fields like the ones talked about above under IS_COMPAT() in the native
hypercall.

Jan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.