[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
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. 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |