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] [PATCH 6/7, RFC] x86_64: basic changes for supporting co

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 6/7, RFC] x86_64: basic changes for supporting compatibility mode guest
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 23 Aug 2006 13:10:19 +0200
Delivery-date: Wed, 23 Aug 2006 04:10:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C111EE4C.1456%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44EC473E.76E4.0078.0@xxxxxxxxxx> <C111EE4C.1456%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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