[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


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 23 Aug 2006 11:36:44 +0100
  • Delivery-date: Wed, 23 Aug 2006 03:37:02 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbGoAbuRacTqjKTEduhlQAKle7CWA==
  • Thread-topic: [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


 


Rackspace

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