| Message ID | 20231012041051.2572507-13-alistair.francis@wdc.com |
|---|---|
| State | New |
| Headers | show |
| Series | [PULL,01/54] target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[] | expand |
On 10/11/23 21:10, Alistair Francis wrote: > From: Daniel Henrique Barboza <dbarboza@ventanamicro.com> > > The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU > Core Definition"), being around since the beginning. It's not an easy > CPU to use: it's undocumented and its name doesn't tell users much about > what the CPU is supposed to bring. 'git log' doesn't help us either in > knowing what was the original design of this CPU type. > > The closest we have is a comment from Alistair [1] where he recalls from > memory that the 'any' CPU is supposed to behave like the newly added > 'max' CPU. He also suggested that the 'any' CPU should be removed. > > The default CPUs are rv32 and rv64, so removing the 'any' CPU will have > impact only on users that might have a script that uses '-cpu any'. > And those users are better off using the default CPUs or the new 'max' > CPU. > > We would love to just remove the code and be done with it, but one does > not simply remove a feature in QEMU. We'll put the CPU in quarantine > first, letting users know that we have the intent of removing it in the > future. > > [1] https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02891.html > > Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> > Reviewed-by: Alistair Francis <alistair.francis@wdc.com> > Reviewed-by: Andrew Jones <ajones@ventanamicro.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> > Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> > Message-ID: <20230912132423.268494-13-dbarboza@ventanamicro.com> > Signed-off-by: Alistair Francis <alistair.francis@wdc.com> > --- > docs/about/deprecated.rst | 12 ++++++++++++ > target/riscv/cpu.c | 5 +++++ > 2 files changed, 17 insertions(+) > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst > index 8b136320e2..5e3965a674 100644 > --- a/docs/about/deprecated.rst > +++ b/docs/about/deprecated.rst > @@ -327,6 +327,18 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under > which the 9p ``proxy`` backend currently suffers. However as of to date nobody > has indicated plans for such kind of reimplementation unfortunately. > > +RISC-V 'any' CPU type ``-cpu any`` (since 8.2) You forgot to update linux-user/riscv/target_elf.h, which still uses "any", and thus all qemu-riscv64 invocations trigger the warning. r~
On 10/19/23 15:13, Richard Henderson wrote: > On 10/11/23 21:10, Alistair Francis wrote: >> From: Daniel Henrique Barboza <dbarboza@ventanamicro.com> >> >> The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU >> Core Definition"), being around since the beginning. It's not an easy >> CPU to use: it's undocumented and its name doesn't tell users much about >> what the CPU is supposed to bring. 'git log' doesn't help us either in >> knowing what was the original design of this CPU type. >> >> The closest we have is a comment from Alistair [1] where he recalls from >> memory that the 'any' CPU is supposed to behave like the newly added >> 'max' CPU. He also suggested that the 'any' CPU should be removed. >> >> The default CPUs are rv32 and rv64, so removing the 'any' CPU will have >> impact only on users that might have a script that uses '-cpu any'. >> And those users are better off using the default CPUs or the new 'max' >> CPU. >> >> We would love to just remove the code and be done with it, but one does >> not simply remove a feature in QEMU. We'll put the CPU in quarantine >> first, letting users know that we have the intent of removing it in the >> future. >> >> [1] https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02891.html >> >> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> >> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> >> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> >> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> >> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> >> Message-ID: <20230912132423.268494-13-dbarboza@ventanamicro.com> >> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> >> --- >> docs/about/deprecated.rst | 12 ++++++++++++ >> target/riscv/cpu.c | 5 +++++ >> 2 files changed, 17 insertions(+) >> >> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst >> index 8b136320e2..5e3965a674 100644 >> --- a/docs/about/deprecated.rst >> +++ b/docs/about/deprecated.rst >> @@ -327,6 +327,18 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under >> which the 9p ``proxy`` backend currently suffers. However as of to date nobody >> has indicated plans for such kind of reimplementation unfortunately. >> +RISC-V 'any' CPU type ``-cpu any`` (since 8.2) > > You forgot to update linux-user/riscv/target_elf.h, which still uses "any", and thus all qemu-riscv64 invocations trigger the warning. Ouch. I'll send a patch. Thanks, Daniel > > > r~ >
On Thu, 19 Oct 2023 at 19:32, Daniel Henrique Barboza <dbarboza@ventanamicro.com> wrote: > > > > On 10/19/23 15:13, Richard Henderson wrote: > > On 10/11/23 21:10, Alistair Francis wrote: > >> From: Daniel Henrique Barboza <dbarboza@ventanamicro.com> > >> > >> The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU > >> Core Definition"), being around since the beginning. It's not an easy > >> CPU to use: it's undocumented and its name doesn't tell users much about > >> what the CPU is supposed to bring. 'git log' doesn't help us either in > >> knowing what was the original design of this CPU type. > >> > >> The closest we have is a comment from Alistair [1] where he recalls from > >> memory that the 'any' CPU is supposed to behave like the newly added > >> 'max' CPU. He also suggested that the 'any' CPU should be removed. > >> > >> The default CPUs are rv32 and rv64, so removing the 'any' CPU will have > >> impact only on users that might have a script that uses '-cpu any'. > >> And those users are better off using the default CPUs or the new 'max' > >> CPU. > >> > >> We would love to just remove the code and be done with it, but one does > >> not simply remove a feature in QEMU. We'll put the CPU in quarantine > >> first, letting users know that we have the intent of removing it in the > >> future. > >> > >> [1] https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02891.html > >> > >> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> > >> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> > >> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> > >> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> > >> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> > >> Message-ID: <20230912132423.268494-13-dbarboza@ventanamicro.com> > >> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> > >> --- > >> docs/about/deprecated.rst | 12 ++++++++++++ > >> target/riscv/cpu.c | 5 +++++ > >> 2 files changed, 17 insertions(+) > >> > >> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst > >> index 8b136320e2..5e3965a674 100644 > >> --- a/docs/about/deprecated.rst > >> +++ b/docs/about/deprecated.rst > >> @@ -327,6 +327,18 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under > >> which the 9p ``proxy`` backend currently suffers. However as of to date nobody > >> has indicated plans for such kind of reimplementation unfortunately. > >> +RISC-V 'any' CPU type ``-cpu any`` (since 8.2) > > > > You forgot to update linux-user/riscv/target_elf.h, which still uses "any", and thus all qemu-riscv64 invocations trigger the warning. > > Ouch. I'll send a patch. This is probably why the 'any' cpu exists in the first place, incidentally -- linux-user wants a way to say "run any binary you can", and for a lot of architectures that was done by having an "any" CPU type that turned on all known features. The idea of having "max" and making it available to system emulation as well as usermode is a bit of a later development. thanks -- PMM
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 8b136320e2..5e3965a674 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -327,6 +327,18 @@ QEMU's ``vhost`` feature, which would eliminate the high latency costs under which the 9p ``proxy`` backend currently suffers. However as of to date nobody has indicated plans for such kind of reimplementation unfortunately. +RISC-V 'any' CPU type ``-cpu any`` (since 8.2) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The 'any' CPU type was introduced back in 2018 and has been around since the +initial RISC-V QEMU port. Its usage has always been unclear: users don't know +what to expect from a CPU called 'any', and in fact the CPU does not do anything +special that isn't already done by the default CPUs rv32/rv64. + +After the introduction of the 'max' CPU type, RISC-V now has a good coverage +of generic CPUs: rv32 and rv64 as default CPUs and 'max' as a feature complete +CPU for both 32 and 64 bit builds. Users are then discouraged to use the 'any' +CPU type starting in 8.2. Block device options '''''''''''''''''''' diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index c9de7ddb4e..115c2d2fa4 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -1522,6 +1522,11 @@ static void riscv_cpu_realize(DeviceState *dev, Error **errp) RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(dev); Error *local_err = NULL; + if (object_dynamic_cast(OBJECT(dev), TYPE_RISCV_CPU_ANY) != NULL) { + warn_report("The 'any' CPU is deprecated and will be " + "removed in the future."); + } + cpu_exec_realizefn(cs, &local_err); if (local_err != NULL) { error_propagate(errp, local_err);