> -----Original Message----- > From: Richard Henderson [mailto:richard.hender...@linaro.org] > Sent: Friday, October 2, 2020 1:28 AM > To: Jiangyifei <jiangyi...@huawei.com>; qemu-devel@nongnu.org; > qemu-ri...@nongnu.org > Cc: Zhanghailiang <zhang.zhanghaili...@huawei.com>; > sag...@eecs.berkeley.edu; kbast...@mail.uni-paderborn.de; Zhangxiaofeng > (F) <victor.zhangxiaof...@huawei.com>; alistair.fran...@wdc.com; yinyipeng > <yinyipe...@huawei.com>; pal...@dabbelt.com; Wubin (H) > <wu.wu...@huawei.com>; dengkai (A) <dengk...@huawei.com> > Subject: Re: [PATCH 3/5] target/riscv: Add H extention state description > > 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. > > 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~
Thank you for your comments. As Alistair said, Those vs* are Virtual Supervisor CSRs. Hypervisor may write those. Actually，except *_hs, all states are real CSRs and cannot be regenerated. *_hs are backup of Supervisor CSRs when V=1，so, I don't think could re-generate them. In conclusion, I think all H extension states in this patch need to be described in vmstate. Yifei
