Daniel Henrique Barboza <dbarb...@ventanamicro.com> writes: > Björn reported in [1] a case where a rv64 CPU is going through the > profile code path to enable satp mode. In this case,the amount of > extensions on top of the rv64 CPU made it compliant with the RVA22S64 > profile during the validation of CPU 0. When the subsequent CPUs were > initialized the static profile object has the 'enable' flag set, > enabling the profile code path for those CPUs. > > This happens because we are initializing and realizing each CPU before > going to the next, i.e. init and realize CPU0, then init and realize > CPU1 and so on. If we change any persistent state during the validation > of CPU N it will interfere with the init/realization of CPU N+1. > > We're using the 'enabled' profile flag to do two distinct things: inform > cpu_init() that we want profile extensions to be enabled, and telling > QMP that a profile is currently enabled in the CPU. We want to be > flexible enough to recognize profile support for all CPUs that has the > extension prerequisites, but we do not want to force the profile code > path if a profile wasn't set too. > > Add a new 'present' flag for profiles that will coexist with the 'enabled' > flag. Enabling a profile means "we want to switch on all its mandatory > extensions". A profile is 'present' if we asserted during validation > that the CPU has the needed prerequisites. > > This means that the case reported by Björn now results in > RVA22S64.enabled=false and RVA22S64.present=true. QMP will recognize it > as a RVA22 compliant CPU and we won't force the CPU into the profile > path. > > [1] > https://lore.kernel.org/qemu-riscv/87y0usiz22....@all.your.base.are.belong.to.us/ > > Reported-by: Björn Töpel <bj...@kernel.org> > Fixes: 2af005d610 ("target/riscv/tcg: validate profiles during finalize") > Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com>
Reviewed-by: Björn Töpel <bj...@rivosinc.com>
