From: Atish Kumar Patra <atishp@rivosinc.com>
To: Conor.Dooley@microchip.com
Cc: qemu-devel@nongnu.org, alistair.francis@wdc.com,
bin.meng@windriver.com, palmer@dabbelt.com,
qemu-riscv@nongnu.org
Subject: Re: [PATCH v14 4/5] hw/riscv: virt: Add PMU DT node to the device tree
Date: Mon, 28 Nov 2022 12:41:41 -0800 [thread overview]
Message-ID: <CAHBxVyGVigqBLLS9vqas+uq=Joyr2F6ir0zqtg+0y2GaTCyX-A@mail.gmail.com> (raw)
In-Reply-To: <a3c7174d-6d33-5a34-0cd5-8ac340c052c3@microchip.com>
On Mon, Nov 28, 2022 at 12:38 PM <Conor.Dooley@microchip.com> wrote:
>
> On 28/11/2022 20:16, Atish Kumar Patra wrote:
> > On Thu, Nov 24, 2022 at 5:17 AM Conor Dooley <conor.dooley@microchip.com> wrote:
> >>
> >> On Wed, Aug 24, 2022 at 03:17:00PM -0700, Atish Patra wrote:
> >>> Qemu virt machine can support few cache events and cycle/instret counters.
> >>> It also supports counter overflow for these events.
> >>>
> >>> Add a DT node so that OpenSBI/Linux kernel is aware of the virt machine
> >>> capabilities. There are some dummy nodes added for testing as well.
> >>
> >> Hey Atish!
> >>
> >> I was fiddling with dumping the virt machine dtb again today to check
> >> some dt-binding changes I was making for the isa string would play
> >> nicely with the virt machine & I noticed that this patch has introduced
> >> a new validation failure:
> >>
> >> ./build/qemu-system-riscv64 -nographic -machine virt,dumpdtb=qemu.dtb
> >>
> >> dt-validate -p ../linux/Documentation/devicetree/bindings/processed-schema.json qemu.dtb
> >> /home/conor/stuff/qemu/qemu.dtb: soc: pmu: {'riscv,event-to-mhpmcounters': [[1, 1, 524281, 2, 2, 524284, 65561, 65561, 524280, 65563, 65563, 524280, 65569, 65569, 524280, 0, 0, 0, 0, 0]], 'compatible': ['riscv,pmu']} should not be valid under {'type': 'object'}
> >> From schema: /home/conor/.local/lib/python3.10/site-packages/dtschema/schemas/simple-bus.yaml
> >>
> >> I assume this is the aforementioned "dummy" node & you have no intention
> >> of creating a binding for this?
> >>
> >
> > It is a dummy node from Linux kernel perspective. OpenSbi use this
> > node to figure out the hpmcounter mappings.
>
> Aye, but should it not have a binding anyway, since they're not
> meant to be linux specific?
>
It is documented in OpenSBI.
https://github.com/riscv-software-src/opensbi/blob/master/docs/pmu_support.md
Are you suggesting that any non-Linux specific DT nodes should be part
of Linux DT binding as well ?
> >>> Acked-by: Alistair Francis <alistair.francis@wdc.com>
> >>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> >>> Signed-off-by: Atish Patra <atishp@rivosinc.com>
> >>> ---
> >>> hw/riscv/virt.c | 16 +++++++++++++
> >>> target/riscv/pmu.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++
> >>> target/riscv/pmu.h | 1 +
> >>> 3 files changed, 74 insertions(+)
> >>>
> >>> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> >>> index ff8c0df5cd47..befa9d2c26ac 100644
> >>> --- a/hw/riscv/virt.c
> >>> +++ b/hw/riscv/virt.c
> >>> @@ -30,6 +30,7 @@
> >>> #include "hw/char/serial.h"
> >>> #include "target/riscv/cpu.h"
> >>> #include "hw/core/sysbus-fdt.h"
> >>> +#include "target/riscv/pmu.h"
> >>> #include "hw/riscv/riscv_hart.h"
> >>> #include "hw/riscv/virt.h"
> >>> #include "hw/riscv/boot.h"
> >>> @@ -708,6 +709,20 @@ static void create_fdt_socket_aplic(RISCVVirtState *s,
> >>> aplic_phandles[socket] = aplic_s_phandle;
> >>> }
> >>>
> >>> +static void create_fdt_pmu(RISCVVirtState *s)
> >>> +{
> >>> + char *pmu_name;
> >>> + MachineState *mc = MACHINE(s);
> >>> + RISCVCPU hart = s->soc[0].harts[0];
> >>> +
> >>> + pmu_name = g_strdup_printf("/soc/pmu");
> >>> + qemu_fdt_add_subnode(mc->fdt, pmu_name);
> >>> + qemu_fdt_setprop_string(mc->fdt, pmu_name, "compatible", "riscv,pmu");
> >>> + riscv_pmu_generate_fdt_node(mc->fdt, hart.cfg.pmu_num, pmu_name);
> >>> +
> >>> + g_free(pmu_name);
> >>> +}
> >>> +
> >>> static void create_fdt_sockets(RISCVVirtState *s, const MemMapEntry *memmap,
> >>> bool is_32_bit, uint32_t *phandle,
> >>> uint32_t *irq_mmio_phandle,
> >>> @@ -1036,6 +1051,7 @@ static void create_fdt(RISCVVirtState *s, const MemMapEntry *memmap,
> >>>
> >>> create_fdt_flash(s, memmap);
> >>> create_fdt_fw_cfg(s, memmap);
> >>> + create_fdt_pmu(s);
> >>>
> >>> update_bootargs:
> >>> if (cmdline && *cmdline) {
> >>> diff --git a/target/riscv/pmu.c b/target/riscv/pmu.c
> >>> index a5f504e53c88..b8e56d2b7b8e 100644
> >>> --- a/target/riscv/pmu.c
> >>> +++ b/target/riscv/pmu.c
> >>> @@ -20,11 +20,68 @@
> >>> #include "cpu.h"
> >>> #include "pmu.h"
> >>> #include "sysemu/cpu-timers.h"
> >>> +#include "sysemu/device_tree.h"
> >>>
> >>> #define RISCV_TIMEBASE_FREQ 1000000000 /* 1Ghz */
> >>> #define MAKE_32BIT_MASK(shift, length) \
> >>> (((uint32_t)(~0UL) >> (32 - (length))) << (shift))
> >>>
> >>> +/*
> >>> + * To keep it simple, any event can be mapped to any programmable counters in
> >>> + * QEMU. The generic cycle & instruction count events can also be monitored
> >>> + * using programmable counters. In that case, mcycle & minstret must continue
> >>> + * to provide the correct value as well. Heterogeneous PMU per hart is not
> >>> + * supported yet. Thus, number of counters are same across all harts.
> >>> + */
> >>> +void riscv_pmu_generate_fdt_node(void *fdt, int num_ctrs, char *pmu_name)
> >>> +{
> >>> + uint32_t fdt_event_ctr_map[20] = {};
> >>> + uint32_t cmask;
> >>> +
> >>> + /* All the programmable counters can map to any event */
> >>> + cmask = MAKE_32BIT_MASK(3, num_ctrs);
> >>> +
> >>> + /*
> >>> + * The event encoding is specified in the SBI specification
> >>> + * Event idx is a 20bits wide number encoded as follows:
> >>> + * event_idx[19:16] = type
> >>> + * event_idx[15:0] = code
> >>> + * The code field in cache events are encoded as follows:
> >>> + * event_idx.code[15:3] = cache_id
> >>> + * event_idx.code[2:1] = op_id
> >>> + * event_idx.code[0:0] = result_id
> >>> + */
> >>> +
> >>> + /* SBI_PMU_HW_CPU_CYCLES: 0x01 : type(0x00) */
> >>> + fdt_event_ctr_map[0] = cpu_to_be32(0x00000001);
> >>> + fdt_event_ctr_map[1] = cpu_to_be32(0x00000001);
> >>> + fdt_event_ctr_map[2] = cpu_to_be32(cmask | 1 << 0);
> >>> +
> >>> + /* SBI_PMU_HW_INSTRUCTIONS: 0x02 : type(0x00) */
> >>> + fdt_event_ctr_map[3] = cpu_to_be32(0x00000002);
> >>> + fdt_event_ctr_map[4] = cpu_to_be32(0x00000002);
> >>> + fdt_event_ctr_map[5] = cpu_to_be32(cmask | 1 << 2);
> >>> +
> >>> + /* SBI_PMU_HW_CACHE_DTLB : 0x03 READ : 0x00 MISS : 0x00 type(0x01) */
> >>> + fdt_event_ctr_map[6] = cpu_to_be32(0x00010019);
> >>> + fdt_event_ctr_map[7] = cpu_to_be32(0x00010019);
> >>> + fdt_event_ctr_map[8] = cpu_to_be32(cmask);
> >>> +
> >>> + /* SBI_PMU_HW_CACHE_DTLB : 0x03 WRITE : 0x01 MISS : 0x00 type(0x01) */
> >>> + fdt_event_ctr_map[9] = cpu_to_be32(0x0001001B);
> >>> + fdt_event_ctr_map[10] = cpu_to_be32(0x0001001B);
> >>> + fdt_event_ctr_map[11] = cpu_to_be32(cmask);
> >>> +
> >>> + /* SBI_PMU_HW_CACHE_ITLB : 0x04 READ : 0x00 MISS : 0x00 type(0x01) */
> >>> + fdt_event_ctr_map[12] = cpu_to_be32(0x00010021);
> >>> + fdt_event_ctr_map[13] = cpu_to_be32(0x00010021);
> >>> + fdt_event_ctr_map[14] = cpu_to_be32(cmask);
> >>> +
> >>> + /* This a OpenSBI specific DT property documented in OpenSBI docs */
> >>> + qemu_fdt_setprop(fdt, pmu_name, "riscv,event-to-mhpmcounters",
> >>> + fdt_event_ctr_map, sizeof(fdt_event_ctr_map));
> >>> +}
> >>> +
> >>> static bool riscv_pmu_counter_valid(RISCVCPU *cpu, uint32_t ctr_idx)
> >>> {
> >>> if (ctr_idx < 3 || ctr_idx >= RV_MAX_MHPMCOUNTERS ||
> >>> diff --git a/target/riscv/pmu.h b/target/riscv/pmu.h
> >>> index 036653627f78..3004ce37b636 100644
> >>> --- a/target/riscv/pmu.h
> >>> +++ b/target/riscv/pmu.h
> >>> @@ -31,5 +31,6 @@ int riscv_pmu_init(RISCVCPU *cpu, int num_counters);
> >>> int riscv_pmu_update_event_map(CPURISCVState *env, uint64_t value,
> >>> uint32_t ctr_idx);
> >>> int riscv_pmu_incr_ctr(RISCVCPU *cpu, enum riscv_pmu_event_idx event_idx);
> >>> +void riscv_pmu_generate_fdt_node(void *fdt, int num_counters, char *pmu_name);
> >>> int riscv_pmu_setup_timer(CPURISCVState *env, uint64_t value,
> >>> uint32_t ctr_idx);
> >>> --
> >>> 2.25.1
> >>>
> >>>
> >>>
> >
next prev parent reply other threads:[~2022-11-28 20:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 22:16 [PATCH v14 0/5] Improve PMU support Atish Patra
2022-08-24 22:16 ` [PATCH v14 1/5] target/riscv: Add sscofpmf extension support Atish Patra
2022-08-24 22:16 ` [PATCH v14 2/5] target/riscv: Simplify counter predicate function Atish Patra
2022-08-24 22:16 ` [PATCH v14 3/5] target/riscv: Add few cache related PMU events Atish Patra
2022-08-24 22:17 ` [PATCH v14 4/5] hw/riscv: virt: Add PMU DT node to the device tree Atish Patra
2022-11-24 13:16 ` Conor Dooley
2022-11-28 20:16 ` Atish Kumar Patra
2022-11-28 20:38 ` Conor.Dooley
2022-11-28 20:41 ` Atish Kumar Patra [this message]
2022-11-28 21:10 ` Conor.Dooley
2022-11-29 7:08 ` Andrew Jones
2022-11-29 7:32 ` Conor.Dooley
2022-11-29 9:27 ` Atish Kumar Patra
2022-11-29 9:42 ` Conor.Dooley
2022-11-29 23:54 ` Conor.Dooley
2022-11-30 8:13 ` Atish Kumar Patra
2022-11-30 8:31 ` Conor.Dooley
2022-08-24 22:17 ` [PATCH v14 5/5] target/riscv: Update the privilege field for sscofpmf CSRs Atish Patra
2022-09-19 22:08 ` [PATCH v14 0/5] Improve PMU support Alistair Francis
2022-09-20 8:36 ` Atish Kumar Patra
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='CAHBxVyGVigqBLLS9vqas+uq=Joyr2F6ir0zqtg+0y2GaTCyX-A@mail.gmail.com' \
--to=atishp@rivosinc.com \
--cc=Conor.Dooley@microchip.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
/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).