All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Arnd Bergmann <arnd@arndb.de>,
	QEMU Development <qemu-devel@nongnu.org>,
	Openrisc <openrisc@lists.librecores.org>
Subject: Re: [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine
Date: Tue, 7 Jun 2022 21:12:07 +0900	[thread overview]
Message-ID: <Yp9Al1UfqvIzStI7@antec> (raw)
In-Reply-To: <CAFEAcA97oraa5OSdqmubmJ2-ONTCTF4ZszwfTcZ9VhqKRFhogA@mail.gmail.com>

On Tue, Jun 07, 2022 at 11:43:08AM +0100, Peter Maydell wrote:
> So I don't have a strong view on whether these devices should
> be DEVICE_NATIVE_ENDIAN or DEVICE_LITTLE_ENDIAN (except that
> my impression is that a DEVICE_LITTLE_ENDIAN device on a
> big-endian system is a bit weird, because it means the guest
> has to byteswap everything. You see that with PCI devices because
> the PCI spec mandates LE, but not often elsewhere).
> 
> If there's an official-ish spec for how goldfish devices are
> supposed to behave (does anybody have a pointer to one?) and it says
> "always little-endian" then that would probably suggest that fixing
> m68k would be nice if we can.

I think there are some conflicting thoughts on this.

In Geert's he mentioned:

  Using Goldfish devices as little-endian devices should be fine.

In Arnd's mail he mentions:

  https://lore.kernel.org/lkml/CAK8P3a1oN8NrUjkh2X8jHQbyz42Xo6GSa=5n0gD6vQcXRjmq1Q@mail.gmail.com/#t

  ... the device was clearly defined as having little-endian
  registers,

Based on that I was thinking that switching to DEVICE_LITTLE_ENDIAN would make
sense.

However, in a followup mail from Laurent we see:

  https://lore.kernel.org/lkml/cb884368-0226-e913-80d2-62d2b7b2e761@vivier.eu/

  The reference document[1] doesn't define the endianness of goldfish.

  [1] https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT


The documentation does not clearly specify it.  So maybe maybe or1k should just
be updated on the linux side and add gf_ioread32/gf_iowrite32 big-endian
accessors.

-Stafford

WARNING: multiple messages have this Message-ID (diff)
From: Stafford Horne <shorne@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Joel Stanley <joel@jms.id.au>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Openrisc <openrisc@lists.librecores.org>,
	QEMU Development <qemu-devel@nongnu.org>
Subject: Re: [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine
Date: Tue, 7 Jun 2022 21:12:07 +0900	[thread overview]
Message-ID: <Yp9Al1UfqvIzStI7@antec> (raw)
In-Reply-To: <CAFEAcA97oraa5OSdqmubmJ2-ONTCTF4ZszwfTcZ9VhqKRFhogA@mail.gmail.com>

On Tue, Jun 07, 2022 at 11:43:08AM +0100, Peter Maydell wrote:
> So I don't have a strong view on whether these devices should
> be DEVICE_NATIVE_ENDIAN or DEVICE_LITTLE_ENDIAN (except that
> my impression is that a DEVICE_LITTLE_ENDIAN device on a
> big-endian system is a bit weird, because it means the guest
> has to byteswap everything. You see that with PCI devices because
> the PCI spec mandates LE, but not often elsewhere).
> 
> If there's an official-ish spec for how goldfish devices are
> supposed to behave (does anybody have a pointer to one?) and it says
> "always little-endian" then that would probably suggest that fixing
> m68k would be nice if we can.

I think there are some conflicting thoughts on this.

In Geert's he mentioned:

  Using Goldfish devices as little-endian devices should be fine.

In Arnd's mail he mentions:

  https://lore.kernel.org/lkml/CAK8P3a1oN8NrUjkh2X8jHQbyz42Xo6GSa=5n0gD6vQcXRjmq1Q@mail.gmail.com/#t

  ... the device was clearly defined as having little-endian
  registers,

Based on that I was thinking that switching to DEVICE_LITTLE_ENDIAN would make
sense.

However, in a followup mail from Laurent we see:

  https://lore.kernel.org/lkml/cb884368-0226-e913-80d2-62d2b7b2e761@vivier.eu/

  The reference document[1] doesn't define the endianness of goldfish.

  [1] https://android.googlesource.com/platform/external/qemu/+/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT


The documentation does not clearly specify it.  So maybe maybe or1k should just
be updated on the linux side and add gf_ioread32/gf_iowrite32 big-endian
accessors.

-Stafford


  reply	other threads:[~2022-06-07 12:12 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27 17:27 [RFC PATCH 0/3] OpenRISC Semihosting and Virt Stafford Horne
2022-05-27 17:27 ` Stafford Horne
2022-05-27 17:27 ` [RFC PATCH 1/3] target/openrisc: Add basic support for semihosting Stafford Horne
2022-05-27 17:27   ` Stafford Horne
2022-06-02 15:39   ` Richard Henderson
2022-06-02 15:39     ` Richard Henderson
2022-06-05  0:57     ` Stafford Horne
2022-06-05  0:57       ` Stafford Horne
2022-06-05 14:36       ` Richard Henderson
2022-06-05 14:36         ` Richard Henderson
2022-05-27 17:27 ` [RFC PATCH 2/3] hw/openrisc: Split re-usable boot time apis out to boot.c Stafford Horne
2022-05-27 17:27   ` Stafford Horne
2022-06-02 15:40   ` Richard Henderson
2022-06-02 15:40     ` Richard Henderson
2022-05-27 17:27 ` [RFC PATCH 3/3] hw/openrisc: Add the OpenRISC virtual machine Stafford Horne
2022-05-27 17:27   ` Stafford Horne
2022-06-02 11:42   ` Joel Stanley
2022-06-02 11:42     ` Joel Stanley
2022-06-02 15:49     ` Richard Henderson
2022-06-02 15:49       ` Richard Henderson
2025-12-10  5:22       ` Philippe Mathieu-Daudé
2025-12-11  8:05         ` Stafford Horne
2022-06-02 19:08     ` Geert Uytterhoeven
2022-06-02 19:08       ` Geert Uytterhoeven
2022-06-02 19:59       ` Stafford Horne
2022-06-02 19:59         ` Stafford Horne
2022-06-03  7:05         ` Geert Uytterhoeven
2022-06-03  7:05           ` Geert Uytterhoeven
2022-06-05  1:58           ` Stafford Horne
2022-06-05  1:58             ` Stafford Horne
2022-06-05  7:32             ` Stafford Horne
2022-06-05  7:32               ` Stafford Horne
2022-06-05  8:19               ` Jason A. Donenfeld
2022-06-05  8:19                 ` Jason A. Donenfeld
2022-06-07  9:48                 ` Jason A. Donenfeld
2022-06-07  9:48                   ` Jason A. Donenfeld
2022-06-07  8:11               ` Geert Uytterhoeven
2022-06-07  8:11                 ` Geert Uytterhoeven
2022-06-07  8:42                 ` Arnd Bergmann
2022-06-07  8:42                   ` Arnd Bergmann
2022-06-07  9:47                   ` Stafford Horne
2022-06-07  9:47                     ` Stafford Horne
2022-06-07 10:04                     ` Arnd Bergmann
2022-06-07 10:04                       ` Arnd Bergmann
2022-06-07 10:43                     ` Peter Maydell
2022-06-07 10:43                       ` Peter Maydell
2022-06-07 12:12                       ` Stafford Horne [this message]
2022-06-07 12:12                         ` Stafford Horne
2022-06-07 14:08                         ` Arnd Bergmann
2022-06-07 14:08                           ` Arnd Bergmann
2025-12-10  5:22                           ` Philippe Mathieu-Daudé
2025-12-11  8:08                             ` Stafford Horne
2022-06-05  2:36     ` Stafford Horne
2022-06-05  2:36       ` Stafford Horne

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=Yp9Al1UfqvIzStI7@antec \
    --to=shorne@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=arnd@arndb.de \
    --cc=openrisc@lists.librecores.org \
    --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 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.