From: Igor Mammedov <imammedo@redhat.com>
To: Michael Clark <mjc@sifive.com>
Cc: qemu-devel@nongnu.org,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
Palmer Dabbelt <palmer@sifive.com>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
RISC-V Patches <patches@groups.riscv.org>
Subject: Re: [Qemu-devel] [PATCH v4 03/22] RISC-V CPU Core Definition
Date: Tue, 6 Feb 2018 16:03:00 +0100 [thread overview]
Message-ID: <20180206160300.17cab7fb@redhat.com> (raw)
In-Reply-To: <CAHNT7NsBQvruhfUpH2aP2BLfiASDU=b7Bsncqpih1ADohxo7cQ@mail.gmail.com>
On Tue, 6 Feb 2018 11:09:56 +1300
Michael Clark <mjc@sifive.com> wrote:
> On Tue, Feb 6, 2018 at 4:04 AM, Igor Mammedov <imammedo@redhat.com> wrote:
>
> > On Mon, 5 Feb 2018 19:22:28 +1300
> > Michael Clark <mjc@sifive.com> wrote:
> >
> > > Add CPU state header, CPU definitions and initialization routines
> > >
> > > Signed-off-by: Michael Clark <mjc@sifive.com>
> > > ---
> > > target/riscv/cpu.c | 385 ++++++++++++++++++++++++++++++
> > ++++++++++++++
> > > target/riscv/cpu.h | 256 +++++++++++++++++++++++++++++
> > > target/riscv/cpu_bits.h | 417 ++++++++++++++++++++++++++++++
> > ++++++++++++++++++
> > > 3 files changed, 1058 insertions(+)
> > > create mode 100644 target/riscv/cpu.c
> > > create mode 100644 target/riscv/cpu.h
> > > create mode 100644 target/riscv/cpu_bits.h
> > >
> > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > > new file mode 100644
> > > index 0000000..684b78b
> > > --- /dev/null
> > > +++ b/target/riscv/cpu.c
> > [...]
> > > +
> > > +static const RISCVCPUInfo riscv_cpus[] = {
> > > +#ifdef CONFIG_USER_ONLY
> > > + { TYPE_RISCV_CPU_ANY, riscv_any_cpu_init },
> > > +#else
> > > + { TYPE_RISCV_CPU_IMAFDCSU_PRIV_1_09, riscv_imafdcsu_priv1_9_cpu_init
> > },
> > > + { TYPE_RISCV_CPU_IMAFDCSU_PRIV_1_10, riscv_imafdcsu_priv1_10_cpu_init
> > },
> > > + { TYPE_RISCV_CPU_IMACU_PRIV_1_10, riscv_imacu_priv1_10_cpu_init
> > },
> > > + { TYPE_RISCV_CPU_IMAC_PRIV_1_10, riscv_imac_priv1_10_cpu_init },
> > > +#endif
> > > + { NULL, NULL }
> > > +};
> > > +
> > [...]
> > > +static void cpu_register(const RISCVCPUInfo *info)
> > > +{
> > > + TypeInfo type_info = {
> > > + .name = info->name,
> > > + .parent = TYPE_RISCV_CPU,
> > > + .instance_size = sizeof(RISCVCPU),
> > > + .instance_init = info->initfn,
> > > + };
> > > +
> > > + type_register(&type_info);
> > > +}
> > > +
> > > +static const TypeInfo riscv_cpu_type_info = {
> > > + .name = TYPE_RISCV_CPU,
> > > + .parent = TYPE_CPU,
> > > + .instance_size = sizeof(RISCVCPU),
> > > + .instance_init = riscv_cpu_init,
> > > + .abstract = false,
> > > + .class_size = sizeof(RISCVCPUClass),
> > > + .class_init = riscv_cpu_class_init,
> > > +};
> > [...]
> >
> > > +static void riscv_cpu_register_types(void)
> > > +{
> > > + const RISCVCPUInfo *info = riscv_cpus;
> > > +
> > > + type_register_static(&riscv_cpu_type_info);
> > > +
> > > + while (info->name) {
> > > + cpu_register(info);
> > > + info++;
> > > + }
> > > +}
> > > +
> > > +type_init(riscv_cpu_register_types)
> > For simplistic type definitions like that,
> > above parts should use DEFINE_TYPES(), see c6678108 for reference.
> >
> >
> > > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > > new file mode 100644
> > > index 0000000..8b816ae
> > > --- /dev/null
> > > +++ b/target/riscv/cpu.h
> > [...]
> > > +#define TYPE_RISCV_CPU "riscv"
> > > +#define TYPE_RISCV_CPU_ANY "riscv-any"
> > > +#define TYPE_RISCV_CPU_IMAFDCSU_PRIV_1_09 "riscv-imafdcsu-priv1.9"
> > > +#define TYPE_RISCV_CPU_IMAFDCSU_PRIV_1_10 "riscv-imafdcsu-priv1.10"
> > > +#define TYPE_RISCV_CPU_IMACU_PRIV_1_10 "riscv-imacu-priv1.10"
> > > +#define TYPE_RISCV_CPU_IMAC_PRIV_1_10 "riscv-imac-priv1.10"
> > > +
> > > +#define RISCV_CPU_TYPE_PREFIX TYPE_RISCV_CPU "-"
> > > +#define RISCV_CPU_TYPE_NAME(name) (RISCV_CPU_TYPE_PREFIX name)
> > it still uses prefix notation versus commonly used suffix in form of
> > "targetFOO-cpu"
> > this prefix approach would get in the way if we try to generalize
> > naming <-> type conversion later[*].
> > So it would better to be consistent with approach qemu uses for cpu types
> > (I believe power had prefix based pnv types but it has been fixed
> > to common suffix based pattern later).
> >
> > * discussion on thread "[PATCH v5 0/6] Add a valid_cpu_types property"
> >
>
> I can reverse them if needed, just it seems a little odd to have riscv on
> the right-hand side of the extensions. I can do this in the v5 spin...
pls, do so + -cpu suffix.
> It may make more sense once we have actual CPU models. Currently, we have
> sets of extensions and privilege ISA versions. I guess these will become
> implicit properties of a specific CPU model and the extensions will be
> visible in the initialization function.
That's what we have in x86 land, code names + _suffix corresponding to
real cpus (mostly) with implicit feature set per each.
Features could be properties so user would be able to enumerate/query/set them.
next prev parent reply other threads:[~2018-02-06 15:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 6:22 [Qemu-devel] [PATCH v4 01/22] RISC-V Maintainers Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 02/22] RISC-V ELF Machine Definition Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 03/22] RISC-V CPU Core Definition Michael Clark
2018-02-05 13:45 ` Richard Henderson
2018-02-05 22:15 ` Michael Clark
2018-02-05 15:04 ` Igor Mammedov
2018-02-05 22:09 ` Michael Clark
2018-02-06 15:03 ` Igor Mammedov [this message]
2018-02-08 2:19 ` Michael Clark
2018-02-08 10:28 ` Igor Mammedov
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 04/22] RISC-V Disassembler Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 05/22] RISC-V CPU Helpers Michael Clark
2018-02-05 13:55 ` Richard Henderson
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 06/22] RISC-V FPU Support Michael Clark
2018-02-05 14:01 ` Richard Henderson
2018-02-05 22:01 ` Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 07/22] RISC-V GDB Stub Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 08/22] RISC-V TCG Code Generation Michael Clark
2018-02-05 14:16 ` Richard Henderson
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 09/22] RISC-V Physical Memory Protection Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 10/22] RISC-V Linux User Emulation Michael Clark
2018-02-05 11:37 ` Andreas Schwab
2018-02-06 1:23 ` Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 11/22] RISC-V HTIF Console Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 12/22] RISC-V HART Array Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 13/22] SiFive RISC-V CLINT Block Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 14/22] SiFive RISC-V PLIC Block Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 15/22] RISC-V Spike Machines Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 16/22] RISC-V VirtIO Machine Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 17/22] SiFive RISC-V UART Device Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 18/22] SiFive RISC-V PRCI Block Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 19/22] SiFive RISC-V Test Finisher Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 20/22] SiFive Freedom E300 RISC-V Machine Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 21/22] SiFive Freedom U500 " Michael Clark
2018-02-05 6:22 ` [Qemu-devel] [PATCH v4 22/22] RISC-V Build Infrastructure Michael Clark
2018-02-05 14:19 ` Richard Henderson
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=20180206160300.17cab7fb@redhat.com \
--to=imammedo@redhat.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=mjc@sifive.com \
--cc=palmer@sifive.com \
--cc=patches@groups.riscv.org \
--cc=qemu-devel@nongnu.org \
--cc=sagark@eecs.berkeley.edu \
/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).