On Mon, Nov 24, 2025 at 06:06:21PM +0100, Radim Krčmář wrote: > 2025-11-19T16:42:20-08:00, Drew Fustini <[email protected]>: > > From: Nicolas Pitre <[email protected]> > > > > Implement a bandwidth controller according to the Capacity and Bandwidth > > QoS Register Interface (CBQRI) which supports these capabilities: > > > > - Number of access types: 2 (code and data) > > - Usage monitoring operations: CONFIG_EVENT, READ_COUNTER > > - Event IDs supported: None, Total read/write byte count, Total > > read byte count, Total write byte count > > - Bandwidth allocation operations: CONFIG_LIMIT, READ_LIMIT > > > > Link: https://github.com/riscv-non-isa/riscv-cbqri/blob/main/riscv-cbqri.pdf > > Signed-off-by: Nicolas Pitre <[email protected]> > > [fustini: add fields introduced in the ratified spec: rpfx and p] > > Signed-off-by: Drew Fustini <[email protected]> > > --- > > diff --git a/hw/riscv/cbqri_bandwidth.c b/hw/riscv/cbqri_bandwidth.c > > +static uint32_t bandwidth_config(RiscvCbqriBandwidthState *bc, > > + uint32_t rcid, uint32_t at, > > + bool *busy) > > +{ > > + BandwidthAllocation *bw_alloc = get_bw_alloc(bc, rcid, at); > > + > > + /* for now we only preserve the current BC_BW_ALLOC register content */ > > There are a few checks that we could do even without any real > accounting, like rbwb > 0, and sum_{rcid}(rcid.rbwb) <= mrbwb.
Good point, I'll add basic checks like that. > Doing so might help us find some bugs in the software management layer. > What is the level of ISA correctness that you're aiming for? > (I'll tone down my review if nitpicks like that are not needed.) The original goal for the Qemu code was for the software proof of concept needed to freeze the spec. I am working on upstreaming the qemu code in order to have a "hardware" implementation to reference when upstreaming the Linux kernel support for resctrl. I do also have access to CBQRI controllers in RTL emulation but that won't be very useful for the purposes of public review of my Linux resctrl patches. Thanks, Drew
