From: Christoffer Dall <christoffer.dall@linaro.org>
To: Anup Patel <anup@brainfault.org>
Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>,
kvm-devel <kvm@vger.kernel.org>,
Victor Kamensky <victor.kamensky@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [Qemu-devel] [Qemu-ppc] KVM and variable-endianness guest CPUs
Date: Thu, 23 Jan 2014 15:28:53 -0800 [thread overview]
Message-ID: <20140123232853.GB2977@lvm> (raw)
In-Reply-To: <CAAhSdy23tpJEzE3uiEpDZgsTUBCow3opD=oR57pKcx7LTUaVhA@mail.gmail.com>
On Wed, Jan 22, 2014 at 02:27:29PM +0530, Anup Patel wrote:
[...]
>
> Thanks for the info on QEMU side handling of MMIO data.
>
> I was not aware that we would be only have "target endian = LE"
> for ARM/ARM64 in QEMU. I think Marc Z had mentioned similar
> thing about MMIO this in our previous discussions on his patches.
> (Please refer, http://www.spinics.net/lists/arm-kernel/msg283313.html)
>
> This clearly means MMIO data passed to user space (QEMU) has
> to of host endianness so that QEMU can take care of bust->device
> endian map.
Hmmm, I'm not sure what you mean exactly, but the fact remains that we
simply need to decide on a layout of mmio.data that (1) doesn't break
existing userspace (2) is clearly defined for mixed-mmio use cases.
>
> Current vcpu_data_guest_to_host() and vcpu_data_host_to_guest()
> does not perform endianness conversion of MMIO data to LE when
> we are running LE guest on BE host so we do need Victor's patch
> for fixing vcpu_data_guest_to_host() and vcpu_data_host_to_guest().
> (Already reported long time back by me,
> http://www.spinics.net/lists/arm-kernel/msg283308.html)
>
The problem is that we cannot decide on how the patch should look like
before the endianness of mmio.data is decided.
Alex, Peter, and I agree that it should be that of the host endianness
and represent what the architecture in question would put on the memory
bus. In the case of ARM, it's the register value when the VCPU E-bit is
clear, and it's the byteswapped register value when the VCPU E-bit is
set.
Therefore, the patch needs to do an unconditional byteswap when the VCPU
E-bit is set, instead of the beXX_to_cpu and cpu_to_beXX.
I'm sending out a patch to clarify the KVM API so we can move on.
-Christoffer
next prev parent reply other threads:[~2014-01-23 23:30 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
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 [this message]
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=20140123232853.GB2977@lvm \
--to=christoffer.dall@linaro.org \
--cc=agraf@suse.de \
--cc=anup@brainfault.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 \
--cc=victor.kamensky@linaro.org \
/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).