From: Peter Maydell <peter.maydell@linaro.org>
To: Alexander Graf <agraf@suse.de>
Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>,
kvm-devel <kvm@vger.kernel.org>,
QEMU Developers <qemu-devel@nongnu.org>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [Qemu-devel] KVM and variable-endianness guest CPUs
Date: Mon, 20 Jan 2014 14:31:21 +0000 [thread overview]
Message-ID: <CAFEAcA9V-E26BR4hB0v1aHHeJV1QsWea0LSdSGfsG1qTpAfpCQ@mail.gmail.com> (raw)
In-Reply-To: <176E0926-A4AF-4D85-9C07-3F32B2AE01B2@suse.de>
On 20 January 2014 14:20, Alexander Graf <agraf@suse.de> wrote:
> I think I see the problem now. You're thinking about LE hosts, not LE guests.
>
> I think the only really sensible options would be to
>
> a) Always use a statically define target endianness (big for ppc)
> b) Always use host endianness
> Currently QEMU apparently implements a), but that can
> easily be changed. Today we don't have kvm support for
> ppc64le hosts yet.
Yes; I would ideally like us be able to get rid of that
statically defined target endianness eventually, so if we
have the leeway to define the kernel<->userspace ABI in a
way that doesn't care about the current guest CPU endianness
(ie we haven't actually yet claimed support for
reverse-endianness guests in a way that locks us into an
unhelpful definition of the ABI) we should take it while
we still can.
Then the current QEMU restrictions boil down to "you can
only use QEMU for KVM on a host kernel with the same
endianness as QEMU's legacy TARGET_WORDS_BIGENDIAN
setting for that CPU" (but such a QEMU can deal with
guests whatever they do with the endianness control bits).
> I personally prefer b). It's the natural thing to do for
> a host interface to be in host endianness and it's exactly
> what we expose for LE-on-BE systems with ppc already.
Yes. Strictly speaking by "host endianness" here I guess
we mean "the endianness of the kernel-to-userspace ABI",
since it is at least in theory possible to have an LE
kernel which runs BE userspace processes.
thanks
-- PMM
next prev parent reply other threads:[~2014-01-20 14:31 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-17 17:53 [Qemu-devel] KVM and variable-endianness guest CPUs Peter Maydell
2014-01-17 18:52 ` Peter Maydell
2014-01-18 4:24 ` Christoffer Dall
2014-01-18 7:32 ` Alexander Graf
2014-01-18 10:15 ` Peter Maydell
2014-01-20 14:20 ` Alexander Graf
2014-01-20 14:31 ` Peter Maydell [this message]
2014-01-20 14:22 ` Alexander Graf
2014-01-20 19:19 ` Christoffer Dall
2014-01-22 5:39 ` Victor Kamensky
2014-01-22 6:31 ` Anup Patel
2014-01-22 6:41 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2014-01-22 7:26 ` Victor Kamensky
2014-01-22 10:52 ` Alexander Graf
2014-01-23 4:25 ` Victor Kamensky
2014-01-23 10:32 ` Alexander Graf
2014-01-23 10:56 ` Greg Kurz
2014-01-22 8:57 ` Anup Patel
2014-01-23 23:28 ` Christoffer Dall
2014-01-22 10:22 ` [Qemu-devel] " Peter Maydell
2014-01-22 17:19 ` Victor Kamensky
2014-01-22 17:29 ` Peter Maydell
2014-01-22 19:29 ` Victor Kamensky
2014-01-22 20:02 ` Peter Maydell
2014-01-22 22:47 ` Victor Kamensky
2014-01-22 23:18 ` Peter Maydell
2014-01-23 0:22 ` Victor Kamensky
2014-01-23 10:23 ` Peter Maydell
2014-01-23 15:06 ` Victor Kamensky
2014-01-23 15:33 ` Peter Maydell
2014-01-23 16:25 ` Victor Kamensky
2014-01-23 20:45 ` Christoffer Dall
2014-01-24 0:50 ` Victor Kamensky
2014-01-24 2:14 ` Christoffer Dall
2014-01-24 4:11 ` Victor Kamensky
2014-01-28 0:32 ` [Qemu-devel] [Qemu-ppc] " Benjamin Herrenschmidt
2014-01-28 0:40 ` Christoffer Dall
2014-01-28 0:15 ` Benjamin Herrenschmidt
2014-01-24 0:09 ` [Qemu-devel] " Victor Kamensky
2014-01-28 0:07 ` [Qemu-devel] [Qemu-ppc] " Benjamin Herrenschmidt
2014-01-28 0:07 ` Benjamin Herrenschmidt
2014-01-27 23:34 ` Benjamin Herrenschmidt
2014-01-27 23:49 ` Peter Maydell
2014-01-28 0:36 ` Benjamin Herrenschmidt
2014-01-28 0:44 ` Christoffer Dall
2014-01-28 4:47 ` Benjamin Herrenschmidt
2014-01-28 16:31 ` Christoffer Dall
2014-01-27 23:31 ` Benjamin Herrenschmidt
2014-01-27 23:27 ` Benjamin Herrenschmidt
2014-01-28 9:16 ` Avi Kivity
2014-01-28 9:04 ` [Qemu-devel] " Avi Kivity
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=CAFEAcA9V-E26BR4hB0v1aHHeJV1QsWea0LSdSGfsG1qTpAfpCQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=agraf@suse.de \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=tlfalcon@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).