All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Stafford Horne <shorne@gmail.com>
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 12:04:14 +0200	[thread overview]
Message-ID: <CAK8P3a3MDDE3ko93E0fMmHoXXveTUeYJXdEJbf0DEy3kcBFn0g@mail.gmail.com> (raw)
In-Reply-To: <Yp8epZsizfKMEVZV@antec>

On Tue, Jun 7, 2022 at 11:47 AM Stafford Horne <shorne@gmail.com> wrote:
> On Tue, Jun 07, 2022 at 10:42:08AM +0200, Arnd Bergmann wrote:

> > Goldfish is a very old platform, as far as I know only the kernel port is new.
> > I don't know when qemu started shipping goldfish, but changing it now would
> > surely break compatibility with whatever OS the port was originally made for.
>
> Hi Arnd,
>
> As far as I can tell goldfish in qemu is not very old. There are 3 devices, 2 were
> added for the m68k virt machine, and 1 for riscv virt.
>
>     $ git lo -- hw/char/goldfish_tty.c
>     2021-11-09 65b4c8c759 Philippe Mathieu-Daudé hw/m68k: Fix typo in SPDX tag
>     2021-03-15 8c6df16ff6 Laurent Vivier   hw/char: add goldfish-tty
>
>     $  git lo -- hw/intc/goldfish_pic.c
>     2021-11-09 65b4c8c759 Philippe Mathieu-Daudé hw/m68k: Fix typo in SPDX tag
>     2021-03-15 8785559390 Laurent Vivier   hw/intc: add goldfish-pic

That is much younger than Laurent made it appear, from his earlier explanations
I expected this to have shipped a long time ago and been used in other
OSs to the
point where it cannot be fixed.

> The mips/loongson3_virt machine now also uses the goldfish_rtc.
>
> The problem with the goldfish device models is that they were defined as
> DEVICE_NATIVE_ENDIAN.
>
>     $ grep endianness hw/*/goldfish*
>     hw/char/goldfish_tty.c:    .endianness = DEVICE_NATIVE_ENDIAN,
>     hw/intc/goldfish_pic.c:    .endianness = DEVICE_NATIVE_ENDIAN,
>     hw/rtc/goldfish_rtc.c:    .endianness = DEVICE_NATIVE_ENDIAN,
>
> RISC-V is little-endian so when it was added there was no problem with running
> linux goldfish drivers.
>
> MIPS Longson3, added last year, seems to be running as little-endian well, I
> understand MIPS can support both big and little endian. However according to
> this all Loongson cores are little-endian.
>
>     https://en.wikipedia.org/wiki/Loongson
>
> As I understand when endianness of the devices in qemu are defined as
> DEVICE_NATIVE_ENDIAN the device endian takes the endian of the target CPU.
>
> This means that MIPS Loongson3 and RISC-V are affectively running as
> little-endian which is what would be expected.

Not really, the definition of DEVICE_NATIVE_ENDIAN in qemu is much less
well-defined than that as I understand, it is just whatever the person adding
support for that CPU thought would be the right one. A lot of CPUs can
run either big-endian or little-endian code, and e.g. on ARM, qemu
DEVICE_NATIVE_ENDIAN is just always little-endian, regardless of
what the CPU runs, while I think on MIPS it would be whatever the CPU
is actually executing.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Stafford Horne <shorne@gmail.com>
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 12:04:14 +0200	[thread overview]
Message-ID: <CAK8P3a3MDDE3ko93E0fMmHoXXveTUeYJXdEJbf0DEy3kcBFn0g@mail.gmail.com> (raw)
In-Reply-To: <Yp8epZsizfKMEVZV@antec>

On Tue, Jun 7, 2022 at 11:47 AM Stafford Horne <shorne@gmail.com> wrote:
> On Tue, Jun 07, 2022 at 10:42:08AM +0200, Arnd Bergmann wrote:

> > Goldfish is a very old platform, as far as I know only the kernel port is new.
> > I don't know when qemu started shipping goldfish, but changing it now would
> > surely break compatibility with whatever OS the port was originally made for.
>
> Hi Arnd,
>
> As far as I can tell goldfish in qemu is not very old. There are 3 devices, 2 were
> added for the m68k virt machine, and 1 for riscv virt.
>
>     $ git lo -- hw/char/goldfish_tty.c
>     2021-11-09 65b4c8c759 Philippe Mathieu-Daudé hw/m68k: Fix typo in SPDX tag
>     2021-03-15 8c6df16ff6 Laurent Vivier   hw/char: add goldfish-tty
>
>     $  git lo -- hw/intc/goldfish_pic.c
>     2021-11-09 65b4c8c759 Philippe Mathieu-Daudé hw/m68k: Fix typo in SPDX tag
>     2021-03-15 8785559390 Laurent Vivier   hw/intc: add goldfish-pic

That is much younger than Laurent made it appear, from his earlier explanations
I expected this to have shipped a long time ago and been used in other
OSs to the
point where it cannot be fixed.

> The mips/loongson3_virt machine now also uses the goldfish_rtc.
>
> The problem with the goldfish device models is that they were defined as
> DEVICE_NATIVE_ENDIAN.
>
>     $ grep endianness hw/*/goldfish*
>     hw/char/goldfish_tty.c:    .endianness = DEVICE_NATIVE_ENDIAN,
>     hw/intc/goldfish_pic.c:    .endianness = DEVICE_NATIVE_ENDIAN,
>     hw/rtc/goldfish_rtc.c:    .endianness = DEVICE_NATIVE_ENDIAN,
>
> RISC-V is little-endian so when it was added there was no problem with running
> linux goldfish drivers.
>
> MIPS Longson3, added last year, seems to be running as little-endian well, I
> understand MIPS can support both big and little endian. However according to
> this all Loongson cores are little-endian.
>
>     https://en.wikipedia.org/wiki/Loongson
>
> As I understand when endianness of the devices in qemu are defined as
> DEVICE_NATIVE_ENDIAN the device endian takes the endian of the target CPU.
>
> This means that MIPS Loongson3 and RISC-V are affectively running as
> little-endian which is what would be expected.

Not really, the definition of DEVICE_NATIVE_ENDIAN in qemu is much less
well-defined than that as I understand, it is just whatever the person adding
support for that CPU thought would be the right one. A lot of CPUs can
run either big-endian or little-endian code, and e.g. on ARM, qemu
DEVICE_NATIVE_ENDIAN is just always little-endian, regardless of
what the CPU runs, while I think on MIPS it would be whatever the CPU
is actually executing.

      Arnd


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

Thread overview: 50+ 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
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 [this message]
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
2022-06-07 12:12                         ` Stafford Horne
2022-06-07 14:08                         ` Arnd Bergmann
2022-06-07 14:08                           ` Arnd Bergmann
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=CAK8P3a3MDDE3ko93E0fMmHoXXveTUeYJXdEJbf0DEy3kcBFn0g@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=Jason@zx2c4.com \
    --cc=openrisc@lists.librecores.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shorne@gmail.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.