qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alistair Francis
Subject: Re: [PATCH 3/5] target/riscv: Add H extention state description
Date: Mon, 5 Oct 2020 15:09:34 -0700

On Thu, Oct 1, 2020 at 10:56 AM Richard Henderson
<richard.henderson@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~
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]