From: Rob Bradford <rbradford@rivosinc.com>
To: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
Andrew Jones <ajones@ventanamicro.com>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
atishp@rivosinc.com, palmer@dabbelt.com,
alistair.francis@wdc.com, bin.meng@windriver.com,
liwei1518@gmail.com, zhiwei_liu@linux.alibaba.com
Subject: Re: [PATCH 3/3] target/riscv: Enable 'B' extension on max CPU type
Date: Thu, 11 Jan 2024 15:49:19 +0000 [thread overview]
Message-ID: <a2a3daf031cef657c62b7ea627d8866fa1742dbb.camel@rivosinc.com> (raw)
In-Reply-To: <ee62a091-5f44-4a25-a724-06393af41807@ventanamicro.com>
On Thu, 2024-01-11 at 11:53 -0300, Daniel Henrique Barboza wrote:
>
>
> On 1/11/24 10:02, Andrew Jones wrote:
> > On Wed, Jan 10, 2024 at 03:32:21PM -0300, Daniel Henrique Barboza
> > wrote:
> > >
> > >
> > > On 1/9/24 14:07, Rob Bradford wrote:
> > > > Signed-off-by: Rob Bradford <rbradford@rivosinc.com>
> > > > ---
> > > > target/riscv/tcg/tcg-cpu.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-
> > > > cpu.c
> > > > index f10871d352..9705daec93 100644
> > > > --- a/target/riscv/tcg/tcg-cpu.c
> > > > +++ b/target/riscv/tcg/tcg-cpu.c
> > > > @@ -999,7 +999,8 @@ static void
> > > > riscv_init_max_cpu_extensions(Object *obj)
> > > > const RISCVCPUMultiExtConfig *prop;
> > > > /* Enable RVG, RVJ and RVV that are disabled by default
> > > > */
> > > > - riscv_cpu_set_misa(env, env->misa_mxl, env->misa_ext | RVG
> > > > | RVJ | RVV);
> > > > + riscv_cpu_set_misa(env, env->misa_mxl,
> > > > + env->misa_ext | RVG | RVJ | RVV | RVB);
> > >
> > > I'm aware that we decided a while ago the 'max' CPU could only
> > > have non-vendor and
> > > non-experimental extensions enabled. RVB is experimental, so in
> > > theory we shouldn't
> > > enable it.
> > >
> > > But RVB is an alias for zba, zbb and zbs, extensions that the
> > > 'max' CPU is already
> > > enabling. In this case I think it's sensible to enable RVB here
> > > since it would
> > > just
> > >
> > > reflect stuff that it's already happening.
> >
> > It's also setting the B bit in misa, which, until this spec is at
> > least
> > frozen, is a reserved bit and reserved bits "must return zero when
> > read".
>
> This is a side effect that I wasn't aware of.
>
> Rob, given that the 'max' CPU already has the zb* extensions enabled,
> is there any
> other gain in enabling RVB in this CPU? If there isn't I'd rather
> leave this one
> out for now.
>
It seems completely reasonable to me to drop it for now.
Thanks for all the feedback,
Rob
>
> Thanks,
>
> Daniel
>
>
> >
> > I don't want to stand in the way of progress and it seems 99.9%
> > likely
> > that the spec will be frozen and ratified, but, if we want to stick
> > to
> > our policies (which we should document), then even the 'max' cpu
> > type
> > should require x-b be added to the command line if it wants the B
> > bit
> > set in misa.
> >
> > Thanks,
> > drew
prev parent reply other threads:[~2024-01-11 15:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 17:07 [PATCH 0/3] target/riscv: Add support for 'B' extension Rob Bradford
2024-01-09 17:07 ` [PATCH 1/3] target/riscv: Add infrastructure for 'B' MISA extension Rob Bradford
2024-01-10 18:18 ` Daniel Henrique Barboza
2024-01-11 13:07 ` Andrew Jones
2024-01-11 13:14 ` Andrew Jones
2024-01-11 15:17 ` Rob Bradford
2024-01-12 16:08 ` Andrew Jones
2024-01-12 16:54 ` Rob Bradford
2024-01-13 0:28 ` Ved Shanbhogue
2024-01-11 13:15 ` Andrew Jones
2024-01-09 17:07 ` [PATCH 2/3] target/riscv: Add step to validate 'B' extension Rob Bradford
2024-01-10 18:26 ` Daniel Henrique Barboza
2024-01-11 13:09 ` Andrew Jones
2024-01-09 17:07 ` [PATCH 3/3] target/riscv: Enable 'B' extension on max CPU type Rob Bradford
2024-01-10 18:32 ` Daniel Henrique Barboza
2024-01-10 18:41 ` Daniel Henrique Barboza
2024-01-11 13:02 ` Andrew Jones
2024-01-11 14:53 ` Daniel Henrique Barboza
2024-01-11 15:49 ` Rob Bradford [this message]
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=a2a3daf031cef657c62b7ea627d8866fa1742dbb.camel@rivosinc.com \
--to=rbradford@rivosinc.com \
--cc=ajones@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=atishp@rivosinc.com \
--cc=bin.meng@windriver.com \
--cc=dbarboza@ventanamicro.com \
--cc=liwei1518@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).