Hello,
This is a follow-up from the solo patch [1] that I decided to split in
a short 2 patch follow-up.
As seen in [2] we faced a situation where we were unable to set a
dynamic array length in the existing VMSTATE_UINT64_ARRAY() macro,
having to resort to VMSTATE_VARRAY_UINT32(). But that also means that
the env.tdata1/2/3 arrays can't be statically allocated, so we'll need
to dynamic allocate that. But if we're doing that, why not do dynamic
alloc in all other trigger related arrays and avoid the extra footprint
in CPURISCVState.
And here we are. Patch 1 is a prep patch that parametrizes the number
of triggers in a new env->num_triggers (changed from trigger_count after
seeing a pattern of calling this type of field num_stuffs) field. This
will serve as array length for all the trigger related arrays, that are
now dynamically allocated.
Patch 2 does the rest of the work by creating an user facing
'num-triggers' property and a CPUDef '.num_trigger' property to allow
CPUs to customize the amount of debug triggers.
Patches based on alistair/riscv-to-apply.next.
Changes from v1:
- patch 1 (new):
- all debug trigger arrays are now dynamically allocated during
realize() time;
- env->num_triggers is the length of these arrays.
- patch 2:
- changed property name from trigger-count to num-triggers;
- changed CPUDef field name from .trigger_count to .num_triggers'.
- v1 link:
https://lore.kernel.org/qemu-devel/[email protected]/
[1]
https://lore.kernel.org/qemu-devel/[email protected]/
[2]
https://lore.kernel.org/qemu-devel/[email protected]/
Daniel Henrique Barboza (2):
target/riscv: dynamic alloc of debug trigger arrays
target/riscv: add 'num-triggers' debug property
target/riscv/cpu.c | 11 +++++++++++
target/riscv/cpu.h | 37 ++++++++++++++++++++++++++++++-------
target/riscv/csr.c | 2 +-
target/riscv/debug.c | 31 +++++++++++++++++++++++--------
target/riscv/machine.c | 16 +++++++++++-----
5 files changed, 76 insertions(+), 21 deletions(-)
--
2.43.0
