Re: [Qemu-ppc] pseries-2.6 migration from QEMU-2.6 to QEMU-2.7 broken

[David Gibson]

On Thu, Sep 22, 2016 at 09:37:16PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2016-09-22 at 13:27 +0200, Cédric Le Goater wrote:
> 
> > > TCG migration succeeds and proceeds ahead. But fails somewhere
> > > ahead in
> > > powerpc exception handler:
> > > 
> > > [qemu]$ ./ppc64-softmmu/qemu-system-ppc64  -machine pseries-
> > > 2.6,usb=off -vga none -nographic -m 2G   ../../imgs/guest.disk
> > > -monitor pty --incoming tcp:localhost:4444 
> > > char device redirected to /dev/pts/5 (label compat_monitor0)
> > > ppc_kvm_enabled: is kvm enabled 0
> > > get_insns_equal: 
> > > Did not match, ignore 9223477658187168481 != 9223477658187151905
> > > ppc_kvm_enabled: is kvm enabled 0
> > > get_insns_equal: 
> > > Did not match, ignore 331702 != 69558
> > > Cannot open font file True
> > > Cannot open font file True
> > > qemu: fatal: Trying to deliver HV exception 4 with no HV support
> > 
> > hmm, this is because we added MSR_HVB in msr_mask AFAICT. we should
> > have a similar vmstate op for it I think
> 
> We also need to be careful about now allowing KVM migration to/from
> wildly different CPU generations, or is that handled elsewhere ? (PVR
> match ?)

Apparently not.  We do transfer the PVR value in the migration stream
(along with all actual and potential SPRs).  However in
cpu_post_load() from target-ppc/machine.c, we overwrite the incoming
value with the PVR for the command line selected CPU model.

We should check it though - that would make for a much, well, saner,
sanity check than comparing the instruction support bitmaps.

For TCG and KVM PR, just comparing for equality should be fine -
you're supposed to match PVRs at either end of the migration, just as
you have to match the rest of the hardware configuration.

For KVM HV there's a bit of a nit: that would disallow migration
between host cpus which aren't exactly the same model, but are close
enough that migration will work in practice.


Ok.. here's what I think we need to do:

    1) Remove the VMSTATE_EQUAL checks for the instruction bits, both
       in 2.8 and 2.7-stable.  That will allow migrations to work
       again, albeit requiring the user to be rather careful that the
       cpus really do match at either end.

    2) In 2.8-devel, change cpu_post_load() to check that the migrated
       PVR is the same as the destination PVR.  That will properly
       verify that we have matching CPUs using architected state.  It
       might break some cases of migrating between similar but not
       identical CPUs with -cpu host and KVM HV

    3) Before 2.8 is wrapped up, experiment to see just what cases (2)
       might have broken and come up with some mechanisms to re-allow
       them.

Thoughts?  Objections?

-- 
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