All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>, xen-devel@lists.xensource.com
Subject: Re: [PATCH 6/7, RFC] x86_64: basic changes for supporting compatibility mode guest
Date: Wed, 23 Aug 2006 13:10:19 +0200	[thread overview]
Message-ID: <44EC53BB.76E4.0078.0@novell.com> (raw)
In-Reply-To: <C111EE4C.1456%Keir.Fraser@cl.cam.ac.uk>

>>> 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

  reply	other threads:[~2006-08-23 11:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-23  9:16 [PATCH 6/7, RFC] x86_64: basic changes for supporting compatibility mode guest Jan Beulich
2006-08-23  9:40 ` Keir Fraser
2006-08-23 10:17   ` Jan Beulich
2006-08-23 10:36     ` Keir Fraser
2006-08-23 11:10       ` Jan Beulich [this message]
2006-08-23 11:44       ` Gerd Hoffmann
2006-08-23 10:32   ` Jan Beulich
2006-08-23 10:33     ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44EC53BB.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.