From: Hollis Blanchard <hollisb@us.ibm.com>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: Jeremy Katz <katzj@redhat.com>,
xen-devel@lists.xensource.com, Ian Pratt <Ian.Pratt@cl.cam.ac.uk>
Subject: Re: 32/64-bit hypercall interface
Date: Mon, 3 Oct 2005 14:28:14 -0500 [thread overview]
Message-ID: <200510031428.14824.hollisb@us.ibm.com> (raw)
In-Reply-To: <7F740D512C7C1046AB53446D37200173056C808E@scsmsx402.amr.corp.intel.com>
On Monday 03 October 2005 14:11, Nakajima, Jun wrote:
> In terms of ABI/API, since Xen needs to disiguish 32-bit or 64-bit
> guests anyway at runtime, I don't think we don't need to change the size
> of any types at this point (i.e. before 3.0).
You would instead propose a compatibility layer in Xen? So when a hypercall
from a 32-bit guest arrives at a 64-bit hypervisor, Xen code converts the
32-bit structure into a 64-bit one and passes that pointer on to the rest of
Xen? And then for return values you'd convert the other way. Hmm, and of
course you wouldn't be able to pass 64-bit addresses back, such as via
dom0_tbufcontrol_t.
As mentioned previously, this is the approach Linux uses
(linux/fs/compat_ioctl.c), and it seems less than ideal to me. Since we have
the ability to fix it now (i.e. make the 32-bit and 64-bit ABI identical),
shouldn't we do that rather than this copying/munging layer?
--
Hollis Blanchard
IBM Linux Technology Center
next prev parent reply other threads:[~2005-10-03 19:28 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-03 19:11 32/64-bit hypercall interface Nakajima, Jun
2005-10-03 19:28 ` Hollis Blanchard [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-10-04 21:51 Nakajima, Jun
2005-10-04 22:47 ` Hollis Blanchard
2005-10-04 16:03 Nakajima, Jun
2005-10-04 16:45 ` Andi Kleen
2005-10-03 22:03 Ian Pratt
2005-10-04 18:05 ` Hollis Blanchard
2005-10-05 10:22 ` Keir Fraser
2005-10-03 21:24 Nakajima, Jun
2005-10-04 12:11 ` Andi Kleen
2005-10-04 16:15 ` Hollis Blanchard
2005-10-03 19:56 Ian Pratt
2005-10-03 20:04 ` Jeremy Katz
2005-10-03 21:11 ` Hollis Blanchard
2005-10-03 22:00 ` Keir Fraser
2005-10-04 16:27 ` Hollis Blanchard
2005-10-04 12:08 ` Andi Kleen
2005-10-02 21:21 Ian Pratt
2005-10-01 18:25 Nakajima, Jun
2005-10-03 16:11 ` Jeremy Katz
2005-09-29 13:56 Ian Pratt
2005-09-29 18:17 ` Hollis Blanchard
2005-09-29 20:12 ` Hollis Blanchard
2005-09-29 22:26 ` Keir Fraser
2005-09-29 22:43 ` Keir Fraser
2005-09-30 0:54 ` Andrei Petrov
2005-09-30 8:03 ` Keir Fraser
2005-09-30 15:38 ` Jimi Xenidis
2005-09-30 20:05 ` Ronald G Minnich
2005-09-30 20:28 ` Hollis Blanchard
2005-09-30 20:39 ` Ronald G Minnich
2005-09-30 15:39 ` Hollis Blanchard
2005-09-30 15:45 ` Keir Fraser
2005-09-30 16:34 ` Hollis Blanchard
2005-09-30 16:42 ` Keir Fraser
2005-09-30 17:03 ` Hollis Blanchard
2005-10-01 1:33 ` Jeremy Katz
2005-10-03 19:34 ` Kip Macy
2005-09-30 16:44 ` David
2005-09-30 16:44 ` Keir Fraser
2005-09-30 16:57 ` Hollis Blanchard
2005-09-30 16:55 ` Andrei Petrov
2005-10-03 18:18 ` Hollis Blanchard
2005-09-28 21:36 Hollis Blanchard
2005-09-29 9:00 ` Keir Fraser
2005-09-29 12:41 ` Jimi Xenidis
2005-09-29 13:13 ` 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=200510031428.14824.hollisb@us.ibm.com \
--to=hollisb@us.ibm.com \
--cc=Ian.Pratt@cl.cam.ac.uk \
--cc=jun.nakajima@intel.com \
--cc=katzj@redhat.com \
--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.