From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 6/7, RFC] x86_64: basic changes for supporting compatibility mode guest Date: Wed, 23 Aug 2006 13:10:19 +0200 Message-ID: <44EC53BB.76E4.0078.0@novell.com> References: <44EC473E.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 23.08.06 12:36 >>> >On 23/8/06 11:17 am, "Jan Beulich" 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