On Sat, 25 Jul 2026 at 13:34, Mark Cave-Ayland <[email protected]> wrote: > > In the SPARC CPU state, env->regwptr points into the env->regbase > array at wherever the architectural CWP (current window pointer) says > we are in the register windows. We don't migrate this directly, > since it's a host pointer, so we must ensure it is set up again > after migration load. > > We also have to deal with a special case when CWP is (nwindows - 1). > In this case, while running we keep the "in" register data for this > window in a temporary location at the end of the regbase[] array, so > that generated code doesn't have to special case this "wrap around" > case. In cpu_pre_save() we call cpu_set_cwp() to force a copy of the > wrapped data from its temporary location into the architectural > location in window 0's "out" registers. We then migrate only > (nwindows * 16) entries in the regbase[] array. So on the > destination we need to copy the "in" register data back to its > temporary location again. > > For 32-bit SPARC we get this right, because the CWP is in the PSR. > The get_psr() function does: > env->cwp = 0; > cpu_put_psr_raw(env, val); > which causes cpu_put_psr_raw() to call cpu_set_cwp() in a way that > sets up both regwptr and the wrapped-register data. > > However, for 64-bit SPARC the CWP is not in the PSR, and > cpu_put_psr_raw() will not call cpu_set_cwp(). This leaves the guest > register state in a corrupted state, and the guest will likely crash > on the destination if it didn't happen to be executing with CWP == 0. > > Fix this by adding a custom vmstate_cwp VMStateInfo with corresponding > get_cwp() and put_cwp() helpers which does the same for the 64-bit > case. > > Cc: [email protected] > Signed-off-by: Mark Cave-Ayland <[email protected]> > --- > target/sparc/machine.c | 40 +++++++++++++++++++++++++++++++++++++++- > 1 file changed, 39 insertions(+), 1 deletion(-) > > Thanks to Peter for his original patch and excellent analysis on the > cause of the asan failure whilst running the "sparc64-migration" > functional test. >
Reviewed-by: Peter Maydell <[email protected]> thanks -- PMM
