qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v2 01/76] target/riscv: drop vector 0.7.1 support


From: Alistair Francis
Subject: Re: [RFC v2 01/76] target/riscv: drop vector 0.7.1 support
Date: Mon, 27 Jul 2020 12:55:18 -0700

On Mon, Jul 27, 2020 at 12:54 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 22 Jul 2020 02:15:24 PDT (-0700), frank.chang@sifive.com wrote:
> > From: Frank Chang <frank.chang@sifive.com>
> >
> > Signed-off-by: Frank Chang <frank.chang@sifive.com>
> > ---
> >  target/riscv/cpu.c | 24 ++++++------------------
> >  target/riscv/cpu.h |  2 --
> >  2 files changed, 6 insertions(+), 20 deletions(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > index 228b9bdb5d..2800953e6c 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -106,11 +106,6 @@ static void set_priv_version(CPURISCVState *env, int 
> > priv_ver)
> >      env->priv_ver = priv_ver;
> >  }
> >
> > -static void set_vext_version(CPURISCVState *env, int vext_ver)
> > -{
> > -    env->vext_ver = vext_ver;
> > -}
> > -
> >  static void set_feature(CPURISCVState *env, int feature)
> >  {
> >      env->features |= (1ULL << feature);
> > @@ -339,7 +334,6 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
> > **errp)
> >      CPURISCVState *env = &cpu->env;
> >      RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(dev);
> >      int priv_version = PRIV_VERSION_1_11_0;
> > -    int vext_version = VEXT_VERSION_0_07_1;
> >      target_ulong target_misa = 0;
> >      Error *local_err = NULL;
> >
> > @@ -363,7 +357,6 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
> > **errp)
> >      }
> >
> >      set_priv_version(env, priv_version);
> > -    set_vext_version(env, vext_version);
> >
> >      if (cpu->cfg.mmu) {
> >          set_feature(env, RISCV_FEATURE_MMU);
> > @@ -455,19 +448,14 @@ static void riscv_cpu_realize(DeviceState *dev, Error 
> > **errp)
> >                  return;
> >              }
> >              if (cpu->cfg.vext_spec) {
> > -                if (!g_strcmp0(cpu->cfg.vext_spec, "v0.7.1")) {
> > -                    vext_version = VEXT_VERSION_0_07_1;
> > -                } else {
> > -                    error_setg(errp,
> > -                           "Unsupported vector spec version '%s'",
> > -                           cpu->cfg.vext_spec);
> > -                    return;
> > -                }
> > +                error_setg(errp,
> > +                       "Unsupported vector spec version '%s'",
> > +                       cpu->cfg.vext_spec);
> > +                return;
> >              } else {
> > -                qemu_log("vector verison is not specified, "
> > -                        "use the default value v0.7.1\n");
> > +                qemu_log("vector version is not specified\n");
> > +                return;
> >              }
> > -            set_vext_version(env, vext_version);
> >          }
> >
> >          set_misa(env, RVXLEN | target_misa);
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index eef20ca6e5..6766dcd914 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -79,8 +79,6 @@ enum {
> >  #define PRIV_VERSION_1_10_0 0x00011000
> >  #define PRIV_VERSION_1_11_0 0x00011100
> >
> > -#define VEXT_VERSION_0_07_1 0x00000701
> > -
> >  #define TRANSLATE_PMP_FAIL 2
> >  #define TRANSLATE_FAIL 1
> >  #define TRANSLATE_SUCCESS 0
>
> If I'm reading things correctly, 5.0 did not have the V extension.  This means
> that we can technically drop 0.7.1 from QEMU, as it's never been released.

There is no intention of this making it into 5.1. We are currently in
hard freeze.

The idea is that QEMU 5.1 will support v0.7.1 and then hopefully 5.2
will support v0.9.

> That said, I'd still prefer to avoid dropping 0.7.1 so late in the release
> cycle (it's already soft freeze, right?).  Given the extended length of the V
> extension development process it seems likely that 0.7.1 is going to end up in
> some silicon, which means it would be quite useful to have it in QEMU.

Agreed!

>
> I understand it's a lot more work to maintain multiple vector extensions, but
> it was very useful to have multiple privileged extensions supported in QEMU
> while that was all getting sorted out and as the vector drafts has massive
> differences it'll probably be even more useful.

Hopefully a release will be enough for this as managing both will be a
huge maintenance burden.

Alistair

>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]