RE: [PATCH 3/5] target/riscv: Add H extention state description

[Jiangyifei]

> -----Original Message-----
> From: Richard Henderson [mailto:richard.henderson@linaro.org]
> Sent: Friday, October 2, 2020 1:28 AM
> To: Jiangyifei <jiangyifei@huawei.com>; qemu-devel@nongnu.org;
> qemu-riscv@nongnu.org
> Cc: Zhanghailiang <zhang.zhanghailiang@huawei.com>;
> sagark@eecs.berkeley.edu; kbastian@mail.uni-paderborn.de; Zhangxiaofeng
> (F) <victor.zhangxiaofeng@huawei.com>; Alistair.Francis@wdc.com; yinyipeng
> <yinyipeng1@huawei.com>; palmer@dabbelt.com; Wubin (H)
> <wu.wubin@huawei.com>; dengkai (A) <dengkai1@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