From: Alistair Francis <alistair23@gmail.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Alistair Francis <Alistair.Francis@wdc.com>,
Bin Meng <bmeng.cn@gmail.com>,
Richard Henderson <richard.henderson@linaro.org>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 16/16] hw/riscv: Use the CPU to determine if 32-bit
Date: Thu, 17 Dec 2020 09:42:20 -0800 [thread overview]
Message-ID: <CAKmqyKNakioM7F0s3C=W5vaUP8UdCoKGo5cXnTwcm3jGCbEsGw@mail.gmail.com> (raw)
In-Reply-To: <mhng-18cffb57-6f85-430d-aa0e-bf19e4698c9a@palmerdabbelt-glaptop>
On Thu, Dec 17, 2020 at 9:25 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Thu, 17 Dec 2020 05:58:11 PST (-0800), richard.henderson@linaro.org wrote:
> > On 12/17/20 12:44 AM, Bin Meng wrote:
> >> What happens if something like ARM big.LITTLE needs to be supported on RISC-V?
> >
> > I'd say it's the board's job to pass the boot heart.
> > (Though even big.LITTLE doesn't mix 64 and 32-bit cores.)
>
> I guess we can't stop people from building crazy things, but it does seem like
> building a system that mixes up base ISAs is unlikely. IDK if 32-bit
> compatibility on 64-bit systems is ever going to be important enough to show up
> on RISC-V, as 32-bit might be defunct in portable systems by the point real
> RISC-V systems are availiable, but one could imagine systems where only a
> subset of cores have 32-bit compatibility. My guess is that they'd all boot
> into 64-bit mode, though, so that sort of stuff won't be relevant until one
> tries to get to 32-bit code.
>
> Regardless of where that sort of thing goes, it seems reasonable to just ban
> people from spinning up mixed machine XLEN systems in QEMU for the time being.
> IIUC that's always been impossible (as it was a #define before), so it's not
> like we're regressing on any functionality with that constraint.
I agree. Currently we don't get anywhere close to allowing mixed XLEN systems.
Allowing 32-bit and 64-bit CPUs on a system is a useful goal, as for
example that is what the HiFive 1 has. As richard said though the main
interest at this point is the boot CPU, which the board can specify
different harts depending on what it is doing.
This is just the first step to making RISC-V more flexible with XLEN,
there will be more patches in the future to continue improving this.
I'm going to apply this series today.
Alistair
>
> Other hetergenous ISA/microarctucture stuff seems reasonable to support in
> QEMU, but also not a high priority. It doesn't seem that hard to write the
> early boot stuff in a way such that it only depends on the base ISA -- that's
> essentially how we're handling stuff like F/D in Linux, you just either probe
> or handle the traps. There's already some simple hetergenous stuff floating
> around (like the non-MMU cores in the SiFive designs) and that all seems to
> work fine so my guess is we have enough stuff there, but I'm sure there'll be
> more work do to as more complicated designs start to show up (doubly so as
> there's no specs for any of this).
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Francis <alistair23@gmail.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Richard Henderson <richard.henderson@linaro.org>,
Bin Meng <bmeng.cn@gmail.com>,
Alistair Francis <Alistair.Francis@wdc.com>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 16/16] hw/riscv: Use the CPU to determine if 32-bit
Date: Thu, 17 Dec 2020 09:42:20 -0800 [thread overview]
Message-ID: <CAKmqyKNakioM7F0s3C=W5vaUP8UdCoKGo5cXnTwcm3jGCbEsGw@mail.gmail.com> (raw)
In-Reply-To: <mhng-18cffb57-6f85-430d-aa0e-bf19e4698c9a@palmerdabbelt-glaptop>
On Thu, Dec 17, 2020 at 9:25 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Thu, 17 Dec 2020 05:58:11 PST (-0800), richard.henderson@linaro.org wrote:
> > On 12/17/20 12:44 AM, Bin Meng wrote:
> >> What happens if something like ARM big.LITTLE needs to be supported on RISC-V?
> >
> > I'd say it's the board's job to pass the boot heart.
> > (Though even big.LITTLE doesn't mix 64 and 32-bit cores.)
>
> I guess we can't stop people from building crazy things, but it does seem like
> building a system that mixes up base ISAs is unlikely. IDK if 32-bit
> compatibility on 64-bit systems is ever going to be important enough to show up
> on RISC-V, as 32-bit might be defunct in portable systems by the point real
> RISC-V systems are availiable, but one could imagine systems where only a
> subset of cores have 32-bit compatibility. My guess is that they'd all boot
> into 64-bit mode, though, so that sort of stuff won't be relevant until one
> tries to get to 32-bit code.
>
> Regardless of where that sort of thing goes, it seems reasonable to just ban
> people from spinning up mixed machine XLEN systems in QEMU for the time being.
> IIUC that's always been impossible (as it was a #define before), so it's not
> like we're regressing on any functionality with that constraint.
I agree. Currently we don't get anywhere close to allowing mixed XLEN systems.
Allowing 32-bit and 64-bit CPUs on a system is a useful goal, as for
example that is what the HiFive 1 has. As richard said though the main
interest at this point is the boot CPU, which the board can specify
different harts depending on what it is doing.
This is just the first step to making RISC-V more flexible with XLEN,
there will be more patches in the future to continue improving this.
I'm going to apply this series today.
Alistair
>
> Other hetergenous ISA/microarctucture stuff seems reasonable to support in
> QEMU, but also not a high priority. It doesn't seem that hard to write the
> early boot stuff in a way such that it only depends on the base ISA -- that's
> essentially how we're handling stuff like F/D in Linux, you just either probe
> or handle the traps. There's already some simple hetergenous stuff floating
> around (like the non-MMU cores in the SiFive designs) and that all seems to
> work fine so my guess is we have enough stuff there, but I'm sure there'll be
> more work do to as more complicated designs start to show up (doubly so as
> there's no specs for any of this).
next prev parent reply other threads:[~2020-12-17 17:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 18:22 [PATCH v4 00/16] RISC-V: Start to remove xlen preprocess Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 01/16] hw/riscv: Expand the is 32-bit check to support more CPUs Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 02/16] target/riscv: Add a TYPE_RISCV_CPU_BASE CPU Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 03/16] riscv: spike: Remove target macro conditionals Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 04/16] riscv: virt: " Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 05/16] hw/riscv: boot: Remove compile time XLEN checks Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 06/16] hw/riscv: virt: " Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 07/16] hw/riscv: spike: " Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 08/16] hw/riscv: sifive_u: " Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-17 6:33 ` Bin Meng
2020-12-17 6:33 ` Bin Meng
2020-12-16 18:22 ` [PATCH v4 09/16] target/riscv: fpu_helper: Match function defs in HELPER macros Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 10/16] target/riscv: Add a riscv_cpu_is_32bit() helper function Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 11/16] target/riscv: Specify the XLEN for CPUs Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-16 18:22 ` [PATCH v4 12/16] target/riscv: cpu: Remove compile time XLEN checks Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-17 6:45 ` Bin Meng
2020-12-17 6:45 ` Bin Meng
2020-12-16 18:22 ` [PATCH v4 13/16] target/riscv: cpu_helper: " Alistair Francis
2020-12-16 18:22 ` Alistair Francis
2020-12-17 6:36 ` Bin Meng
2020-12-17 6:36 ` Bin Meng
2020-12-16 18:23 ` [PATCH v4 14/16] target/riscv: csr: " Alistair Francis
2020-12-16 18:23 ` Alistair Francis
2020-12-17 6:37 ` Bin Meng
2020-12-17 6:37 ` Bin Meng
2020-12-16 18:23 ` [PATCH v4 15/16] target/riscv: cpu: Set XLEN independently from target Alistair Francis
2020-12-16 18:23 ` Alistair Francis
2020-12-16 18:23 ` [PATCH v4 16/16] hw/riscv: Use the CPU to determine if 32-bit Alistair Francis
2020-12-16 18:23 ` Alistair Francis
2020-12-16 18:51 ` Richard Henderson
2020-12-16 18:51 ` Richard Henderson
2020-12-17 6:44 ` Bin Meng
2020-12-17 6:44 ` Bin Meng
2020-12-17 13:58 ` Richard Henderson
2020-12-17 13:58 ` Richard Henderson
2020-12-17 17:25 ` Palmer Dabbelt
2020-12-17 17:25 ` Palmer Dabbelt
2020-12-17 17:42 ` Alistair Francis [this message]
2020-12-17 17:42 ` Alistair Francis
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='CAKmqyKNakioM7F0s3C=W5vaUP8UdCoKGo5cXnTwcm3jGCbEsGw@mail.gmail.com' \
--to=alistair23@gmail.com \
--cc=Alistair.Francis@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=richard.henderson@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 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.