From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Alexander Graf <agraf@suse.de>, Drew Jones <drjones@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
qemu devel list <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write()
Date: Wed, 31 Dec 2014 14:20:41 +0100 [thread overview]
Message-ID: <54A3F829.4000509@redhat.com> (raw)
In-Reply-To: <1420024880-15416-1-git-send-email-lersek@redhat.com>
On 31/12/2014 12:21, Laszlo Ersek wrote:
> Because register emulation in QEMU is integer-preserving, not
> string-preserving (see (2)), we have to jump through a few hoops.
>
> (3a) We defined the memory mapped fw_cfg data register as
> DEVICE_BIG_ENDIAN.
>
> The particular choice is not really relevant -- we picked BE only for
> consistency with the control register, which *does* transfer integers --
> but our choice affects how we must host-encode values from fw_cfg strings.
>
> (3b) Since we want the fw_cfg string "XY" to appear as the [0x58, 0x59]
> array on the data register, *and* we picked DEVICE_BIG_ENDIAN, we must
> compose the host (== C language) value 0x5859 in the read accessor
> function.
I'm not sure this is right.
DEVICE_BIG_ENDIAN means that if we return 0xaabb and the guest is little
endian, it will return 0xbbaa. But the value returned by the accessor
is always in host endianness.
And it makes sense to swap in the guest if the register is big endian
but the guest is little endian.
So IMHO your old code is right. Either you are overthinking it, or I'm
underthinking it... Knowing our respective personalities, either
possibility is just as likely... ;)
Paolo
next prev parent reply other threads:[~2014-12-31 13:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 11:21 [Qemu-devel] [PATCH] fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write() Laszlo Ersek
2014-12-31 13:20 ` Paolo Bonzini [this message]
2014-12-31 14:07 ` Laszlo Ersek
2014-12-31 15:17 ` Peter Maydell
2014-12-31 16:23 ` Paolo Bonzini
2014-12-31 17:04 ` Laszlo Ersek
2014-12-31 17:56 ` Paolo Bonzini
2014-12-31 17:29 ` Peter Maydell
2014-12-31 19:25 ` Paolo Bonzini
2014-12-31 19:32 ` Laszlo Ersek
2014-12-31 16:27 ` Laszlo Ersek
2014-12-31 17:17 ` Peter Maydell
2014-12-31 17:37 ` Peter Maydell
2014-12-31 17:59 ` Laszlo Ersek
2014-12-31 18:08 ` Ard Biesheuvel
2014-12-31 18:25 ` Peter Maydell
2015-01-01 10:27 ` Ard Biesheuvel
2014-12-31 18:26 ` Laszlo Ersek
2014-12-31 17:44 ` Peter Maydell
2014-12-31 17:58 ` Laszlo Ersek
2014-12-31 18:22 ` Laszlo Ersek
2015-01-05 15:24 ` Peter Maydell
2015-01-05 15:33 ` Laszlo Ersek
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=54A3F829.4000509@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=drjones@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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).