On Sun, Sep 10, 2017 at 03:37:34PM +0100, Mark Cave-Ayland wrote: > This is referenced in cpu_ppc_handle_mmu_fault() and so should be included > in the migration stream.
That is not, on its own, sufficient reason.
> Note: the vmstate_ppc version number has already been bumped by the previous
> patch in this series.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
As with 2/4 it breaks backwards migration.
But more, I really disklike the idea of migrating this. It's internal
state for one, and it's also essentially transitory state. Can we
avoid putting it in the otherwise persistent structure at all? Can we
derive the state from elsewhere? Can we prevent migration from
occurring in the small windows where this data is live?
> ---
> target/ppc/machine.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/ppc/machine.c b/target/ppc/machine.c
> index 8fec1a4..10b3c41 100644
> --- a/target/ppc/machine.c
> +++ b/target/ppc/machine.c
> @@ -676,7 +676,7 @@ const VMStateDescription vmstate_ppc_cpu = {
>
> /* Internal state */
> VMSTATE_UINTTL(env.hflags_nmsr, PowerPCCPU),
> - /* FIXME: access_type? */
> + VMSTATE_UINT8_V(env.access_type, PowerPCCPU, 6),
>
> /* Interrupt state */
> VMSTATE_UINT32_V(env.pending_interrupts, PowerPCCPU, 6),
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
