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

This introduces
- a (generic) config setting to turn on compatibility mode support
- support to load a Dom0 32-bit ELF image on 64-bit
- a compatibility guest mode GDT (requires moving the ring 0
  selectors to different GDT slots), and the respective selector
  handling changes
- some initial code path changes to address the needs of a
  compatibility mode guest

This changes the ABI in adding to vcpu_guest_context - does a change like
this require bumping the ABI version?

Signed-off-by: Jan Beulich <jbeulich@novell.com>


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

On 23/8/06 10:16 am, "Jan Beulich" <jbeulich@novell.com> wrote:
> This changes the ABI in adding to vcpu_guest_context - does a change like
> this require bumping the ABI version?
We can''t do this as the struct is part of the domU ABI (used for
initialising secondary VCPUs). You''ll have to add the extra CS values
to
64-bit arch_vcpu, I think.

 -- Keir



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

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 23.08.06 11:40
>>>
>On 23/8/06 10:16 am, "Jan Beulich" <jbeulich@novell.com>
wrote:
>
>> This changes the ABI in adding to vcpu_guest_context - does a change
like
>> this require bumping the ABI version?
>
>We can''t do this as the struct is part of the domU ABI (used for
>initialising secondary VCPUs). You''ll have to add the extra CS
values to
>64-bit arch_vcpu, I think.
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.

Jan

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

There was one more issue I forgot to mention: We must disable execution of
''syscall'' in some way for compatibility domains. The question
is whether to
add respective detection code early into the syscall path (which would affect
performance-wise all 64-bit domains) or whether to {dis,en}able the use of
the instruction in the context switch code by updating EFER as needed
(which would have a performance effect only when switching between
a native and a compatibility domain, but the performance effect would likely
be significantly greater). I''d prefer the second option, not the least
because
its implementation is significantly easier.

Jan

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

On 23/8/06 11:32 am, "Jan Beulich" <jbeulich@novell.com> wrote:
> There was one more issue I forgot to mention: We must disable execution of
> ''syscall'' in some way for compatibility domains. The
question is whether to
> add respective detection code early into the syscall path (which would
affect
> performance-wise all 64-bit domains) or whether to {dis,en}able the use of
> the instruction in the context switch code by updating EFER as needed
> (which would have a performance effect only when switching between
> a native and a compatibility domain, but the performance effect would
likely
> be significantly greater). I''d prefer the second option, not the
least because
> its implementation is significantly easier.
I''m not fussed either way really. It depends how slow it is to update
EFER.
That''d be easy to check.

 -- Keir



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

On 23/8/06 11:17 am, "Jan Beulich" <jbeulich@novell.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 23.08.06 12:36
>>>
>On 23/8/06 11:17 am, "Jan Beulich" <jbeulich@novell.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,
> 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.
I think we certainly want to have that.  I''d suggest to have a look at
my kexec bits:

  http://www.suse.de/~kraxel/xen/kexec.html
  http://www.suse.de/~kraxel/patches/

They include a largely rewritten domain builder, adding support for
loading both 32bit and 64bit kernels with the 64bit tools should be easy.
> 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).
I''d suggest to suffix them with $arch instead, so we have the option to
handle even ia64 on x86 machines.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

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