On Thu, Oct 1, 2020 at 10:56 AM Richard Henderson <richard.hender...@linaro.org> wrote: > > On 9/28/20 9:03 PM, Yifei Jiang wrote: > > + VMSTATE_UINTTL(env.vsstatus, RISCVCPU), > > + VMSTATE_UINTTL(env.vstvec, RISCVCPU), > > + VMSTATE_UINTTL(env.vsscratch, RISCVCPU), > > + VMSTATE_UINTTL(env.vsepc, RISCVCPU), > > + VMSTATE_UINTTL(env.vscause, RISCVCPU), > > + VMSTATE_UINTTL(env.vstval, RISCVCPU), > > + VMSTATE_UINTTL(env.vsatp, RISCVCPU), > > So... if I understand things correctly, this is synthetic state, internal to > QEMU. It is generally better to only serialize architectural state, so that > if > qemu internals are rearranged, it is easy to decide on the correct sequence of > operations.
I don't think the virtual registers are synthetic, they contain what the guest Hypervisor/Hypervisor guest wrote to those CSRs. I don't think we could re-generate them from anything else. There are some other registers in this series that I think can be re-generated. The PMP is a good example of that, where the PMP config data could be re-generated from the CSRs. Alistair > > It seems like this should be re-generated with a post_load hook, calling some > of the code currently in riscv_cpu_swap_hypervisor_regs(). Note that some > minor rearrangement would be needed to call that code from this new context. > > > r~ >