The source excerpts below are from QEMU `master` at `ff1d2d19d7e24893e2012d879f8e73077e17b9bd`. ## Host environment - Operating system: Linux - OS/kernel version: 6.0 - Architecture: x86 - QEMU flavor: `qemu-system-riscv64` - QEMU version: qemu.git `ff1d2d19d7e24893e2012d879f8e73077e17b9bd` ## Emulated/Virtualized environment - Operating system: RISC-V guest using Smcntrpmf - Architecture: RISC-V - Accelerator: `TCG` - Relevant CPU/device configuration: Smcntrpmf enabled; non-default privilege filters and accumulated cycle/instret state ## Description of problem ### Background and terminology QEMU live migration serializes CPU state through `VMStateDescription`. A field in `CPURISCVState` is not migrated merely because it exists in the C structure: it must be listed in the main VMState or in a versioned subsection. Omitting guest-visible state makes the destination CPU resume with a reset, zero, or reconstructed value instead of the source value. ### Affected code path The affected implementation locations are: `target/riscv/cpu.h, target/riscv/tcg/pmu.c, and target/riscv/machine.c` Smcntrpmf tracks configuration in `mcyclecfg`/`minstretcfg` and keeps per-privilege fixed-counter accumulators in `PMUFixedCtrState`. Existing PMU VMState serializes programmable-counter `PMUCTRState`, not these fixed-counter fields. ### Current source evidence [target/riscv/cpu.h:242](https://gitlab.com/qemu-project/qemu/-/blob/ff1d2d19d7e24893e2012d879f8e73077e17b9bd/target/riscv/cpu.h#L242) ```c 242 | 243 | typedef struct PMUFixedCtrState { 244 | /* Track cycle and icount for each privilege mode */ 245 | uint64_t counter[4]; 246 | uint64_t counter_prev[4]; 247 | /* Track cycle and icount for each privilege mode when V = 1*/ 248 | uint64_t counter_virt[2]; 249 | uint64_t counter_virt_prev[2]; 250 | } PMUFixedCtrState; 251 | 252 | struct CPUArchState { 253 | uint64_t gpr[32]; 254 | uint64_t gprh[32]; /* 64 top bits of the 128-bit registers */ 255 | ``` [target/riscv/machine.c:388](https://gitlab.com/qemu-project/qemu/-/blob/ff1d2d19d7e24893e2012d879f8e73077e17b9bd/target/riscv/machine.c#L388) ```c 388 | 389 | static const VMStateDescription vmstate_pmu_ctr_state = { 390 | .name = "cpu/pmu", 391 | .version_id = 3, 392 | .minimum_version_id = 3, 393 | .needed = pmu_needed, 394 | .fields = (const VMStateField[]) { 395 | VMSTATE_UINT64(mhpmcounter_val, PMUCTRState), 396 | VMSTATE_UINT64(mhpmcounter_prev, PMUCTRState), 397 | VMSTATE_END_OF_LIST() 398 | } 399 | }; 400 | 401 | static bool jvt_needed(void *opaque) 402 | { 403 | RISCVCPU *cpu = opaque; 404 | 405 | return cpu->cfg.ext_zcmt; 406 | } 407 | ``` ### Root cause analysis The fixed cycle and instret counters are no longer described by one raw counter when privilege filtering is active: QEMU accumulates separate physical/virtual privilege buckets and uses mcyclecfg/minstretcfg to decide which buckets contribute. None of that configuration or accumulator state appears in `target/riscv/machine.c`. Reconstructing only ordinary counter values cannot preserve both the total and future filtering semantics. The reasoning, step by step: 1. The guest configures different inhibit bits for privilege modes and runs code in more than one mode. 2. QEMU accumulates counts in `pmu_fixed_ctrs` buckets under the two configuration CSRs. 3. Migration omits the configuration and bucket arrays. 4. The destination uses reset filters and reset/internal accumulators, producing a discontinuity or different future count rate. ### Worked example and boundary cases Set one fixed-counter privilege-inhibit field and accumulate some count in a permitted mode. Preserve both the configuration and the already-accumulated buckets across migration. A counter-value-only comparison can miss an error that appears only when execution subsequently moves into a mode that should be inhibited. ### Conditions needed to reach the problem - Smcntrpmf is enabled. - mcyclecfg/minstretcfg or a fixed-counter accumulator is non-default. - The guest is live-migrated under TCG. ### Expected or potential effect - cycle/instret can jump, lose accumulated contributions, or count modes that were inhibited. - Performance-monitoring software sees behavior change at the migration boundary. ### Expected behavior mcyclecfg/minstretcfg and the filtered fixed-counter accumulators must retain their values across migration. ## Steps to reproduce The following validation design covers the expected and current-code results. 1. enable Smcntrpmf and program different U/S/M/VS/VU inhibit combinations for cycle and instret. 2. Run calibrated loops in each privilege/virtualization mode and record the two fixed counters. 3. Migrate after at least two accumulator buckets are nonzero. 4. Read the configuration CSRs and counters immediately after migration, then run another calibrated loop. Expected result: Configuration and accumulated fixed-counter state remain continuous across migration. Current behavior: The VMState schema has no entries for either the configuration CSRs or fixed-counter accumulator structure. ## Suggested fix direction Introduce an Smcntrpmf-gated, versioned VMState subsection containing mcyclecfg, minstretcfg, and both `PMUFixedCtrState` instances including physical and virtual buckets and their snapshots. Define pre-save/post-load synchronization so the serialized values represent one coherent virtual-time point. The fix should be covered by the following focused regression checks: - Cycle and instret with different privilege inhibit masks. - Physical and virtual privilege buckets. - Migration with the extension disabled for compatibility. ## References - QEMU source baseline: https://gitlab.com/qemu-project/qemu/-/commit/ff1d2d19d7e24893e2012d879f8e73077e17b9bd ## Additional information - Source baseline: QEMU `master` at `ff1d2d19d7e24893e2012d879f8e73077e17b9bd` (checked 2026-09-05).