All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Ruinland Chuan-Tzu Tsai <ruinland@andestech.com>,
	wangjunqiang <wangjunqiang@iscas.ac.cn>,
	 "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Bin Meng <bin.meng@windriver.com>
Cc: Dylan Jhong <dylan@andestech.com>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"Alan Quey-Liang Kao\(\(\(\(\(\(\(\(\(\(\)"
	<alankao@andestech.com>
Subject: Re: [PATCH V2 0/2] Proposing custom CSR handling logic
Date: Wed, 12 May 2021 16:03:04 +1000	[thread overview]
Message-ID: <CAKmqyKO35O+bichwKQVeZ2tPT+2G-hweds1VY6oJc_bqkuG8Zw@mail.gmail.com> (raw)
In-Reply-To: <20210511100722.18065-1-ruinland@andestech.com>

On Tue, May 11, 2021 at 8:07 PM Ruinland Chuan-Tzu Tsai
<ruinland@andestech.com> wrote:
>
> Hi all,
>
> My sincere apology that I missed the patch to include our own CSR table
> into the patch series and there were plenty of typos.
> Thus I'm sending out V2 of these tiny patches.
>
> I agree with Alistair's comment on not introducing intrusive code which
> will interfere the generic code structure. Yet since there are
> possibilities that some custom CSRs/instructions could be once drafted/
> proposed by vendors at first, and made themselves into the standard
> as the implementation become widely adopted.
>
> So in this patch set, we humbly utilzed a glib hash table for inserting
> the `struct riscv_custom_csr_operations`, check if the CSR is a non
> standard one, and then proceed the desired behavior.
>
> Once the non-standard CSRs make themselves into the specification,
> people could easily plug-and-use the code into CSR operation table
> inside `csr.c`.
>
> Ones may have concerns regarding the check code would introduce
> further overhead. For those considerations, I guess it could be solved
> by introducing a build option such as '--enable-riscv-vendor-features'
> to toggle the code.
>
> Cordially yours,
> Ruinland ChuanTzu Tsai
>
> Ruinland Chuan-Tzu Tsai (2):
>   Adding premliminary support for custom CSR handling mechanism
>   Adding custom Andes CSR table.

Thanks for the patches.

Can you please include:
 wangjunqiang@iscas.ac.cn
 qemu-devel@nongnu.org
 bin.meng@windriver.com

on future patches so everyone is included.

Alistair

>
>  target/riscv/cpu.c           |  28 ++++++++
>  target/riscv/cpu.h           |  12 +++-
>  target/riscv/cpu_bits.h      | 115 ++++++++++++++++++++++++++++++++
>  target/riscv/csr.c           | 107 ++++++++++++++++++++++++++++--
>  target/riscv/csr_andes.inc.c | 125 +++++++++++++++++++++++++++++++++++
>  5 files changed, 381 insertions(+), 6 deletions(-)
>  create mode 100644 target/riscv/csr_andes.inc.c
>
> --
> 2.17.1
>


WARNING: multiple messages have this Message-ID (diff)
From: Alistair Francis <alistair23@gmail.com>
To: Ruinland Chuan-Tzu Tsai <ruinland@andestech.com>,
	wangjunqiang <wangjunqiang@iscas.ac.cn>,
	 "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	Bin Meng <bin.meng@windriver.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
	Dylan Jhong <dylan@andestech.com>,
	 "Alan Quey-Liang Kao(((((((((()" <alankao@andestech.com>
Subject: Re: [PATCH V2 0/2] Proposing custom CSR handling logic
Date: Wed, 12 May 2021 16:03:04 +1000	[thread overview]
Message-ID: <CAKmqyKO35O+bichwKQVeZ2tPT+2G-hweds1VY6oJc_bqkuG8Zw@mail.gmail.com> (raw)
In-Reply-To: <20210511100722.18065-1-ruinland@andestech.com>

On Tue, May 11, 2021 at 8:07 PM Ruinland Chuan-Tzu Tsai
<ruinland@andestech.com> wrote:
>
> Hi all,
>
> My sincere apology that I missed the patch to include our own CSR table
> into the patch series and there were plenty of typos.
> Thus I'm sending out V2 of these tiny patches.
>
> I agree with Alistair's comment on not introducing intrusive code which
> will interfere the generic code structure. Yet since there are
> possibilities that some custom CSRs/instructions could be once drafted/
> proposed by vendors at first, and made themselves into the standard
> as the implementation become widely adopted.
>
> So in this patch set, we humbly utilzed a glib hash table for inserting
> the `struct riscv_custom_csr_operations`, check if the CSR is a non
> standard one, and then proceed the desired behavior.
>
> Once the non-standard CSRs make themselves into the specification,
> people could easily plug-and-use the code into CSR operation table
> inside `csr.c`.
>
> Ones may have concerns regarding the check code would introduce
> further overhead. For those considerations, I guess it could be solved
> by introducing a build option such as '--enable-riscv-vendor-features'
> to toggle the code.
>
> Cordially yours,
> Ruinland ChuanTzu Tsai
>
> Ruinland Chuan-Tzu Tsai (2):
>   Adding premliminary support for custom CSR handling mechanism
>   Adding custom Andes CSR table.

Thanks for the patches.

Can you please include:
 wangjunqiang@iscas.ac.cn
 qemu-devel@nongnu.org
 bin.meng@windriver.com

on future patches so everyone is included.

Alistair

>
>  target/riscv/cpu.c           |  28 ++++++++
>  target/riscv/cpu.h           |  12 +++-
>  target/riscv/cpu_bits.h      | 115 ++++++++++++++++++++++++++++++++
>  target/riscv/csr.c           | 107 ++++++++++++++++++++++++++++--
>  target/riscv/csr_andes.inc.c | 125 +++++++++++++++++++++++++++++++++++
>  5 files changed, 381 insertions(+), 6 deletions(-)
>  create mode 100644 target/riscv/csr_andes.inc.c
>
> --
> 2.17.1
>


  parent reply	other threads:[~2021-05-12  6:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 10:07 [PATCH V2 0/2] Proposing custom CSR handling logic Ruinland Chuan-Tzu Tsai
2021-05-11 10:07 ` [PATCH V2 1/2] Adding premliminary support for custom CSR handling mechanism Ruinland Chuan-Tzu Tsai
2021-05-12  6:16   ` Alistair Francis
2021-05-12 23:41     ` Alistair Francis
2021-05-12 23:41       ` Alistair Francis
2021-05-11 10:07 ` [PATCH V2 2/2] Adding custom Andes CSR table Ruinland Chuan-Tzu Tsai
2021-05-12  6:03 ` Alistair Francis [this message]
2021-05-12  6:03   ` [PATCH V2 0/2] Proposing custom CSR handling logic Alistair Francis
2021-05-12 14:47   ` Bin Meng
2021-05-12 14:47     ` Bin Meng
2021-05-12 23:40     ` Alistair Francis
2021-05-12 23:40       ` 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=CAKmqyKO35O+bichwKQVeZ2tPT+2G-hweds1VY6oJc_bqkuG8Zw@mail.gmail.com \
    --to=alistair23@gmail.com \
    --cc=alankao@andestech.com \
    --cc=bin.meng@windriver.com \
    --cc=dylan@andestech.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=ruinland@andestech.com \
    --cc=wangjunqiang@iscas.ac.cn \
    /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.