Re: [Qemu-ppc] [PATCH v2 0/6] Fix migration issues with arbitrary cpu-hot(un)plug

[Eduardo Habkost]

On Tue, Jul 26, 2016 at 01:16:59PM +1000, David Gibson wrote:
> On Mon, Jul 25, 2016 at 11:59:18AM +0200, Igor Mammedov wrote:
> > Changes from v1:
> >   - be conservative, drop QTAIL_*() macros hunks and do list element
> >     check/cleanup localy in cpu_exec_exit()
> >   - fix conflict caused by above
> >   - update Reviewed-bys fom v1
> >   - drop spapr patches as they will be a bit different and depend
> >     on not yet applied to master patch:
> >      'spapr: disintricate core-id from DT semantics'
> > 
> > Series fixes migration issues caused by unstable cpu_index which depended
> > on order cpus were created/destroyed. It follows David's idea to make
> > cpu_index assignable by selected boards if board supports cpu-hotplug
> > with device_add and needs stable cpu_index/'migration id' but leaves
> > behaviour of the same as before for users that don't care about
> > cpu-hot(un)plug making changes low-risk.
> > 
> > tested with:
> >   SRC -snapshot -enable-kvm -smp 1,maxcpus=3 -m 256M guest.img -monitor 
> > stdio \
> >        -device qemu64-x86_64-cpu,id=cpudel,apic-id=1 \
> >        -device qemu64-x86_64-cpu,apic-id=2 
> >   (qemu) device_del cpudel
> >   (qemu) stop
> >   (qemu) migrate "exec:gzip -c > STATEFILE.gz"
> >   
> >   DST -snapshot -enable-kvm -smp 1,maxcpus=3 -m 256M guest.img -monitor 
> > stdio \
> >       -device qemu64-x86_64-cpu,apic-id=2 \
> >       -incoming "exec: gzip -c -d STATEFILE.gz"
> > 
> > git tree to test with:
> >      https://github.com/imammedo/qemu cpu-index-stable-v2
> >  to view
> >      https://github.com/imammedo/qemu/commits/cpu-index-stable-v2
> 
> Eduardo,
> 
> Igor said he thought these would probably go in via your tree.  Do you
> have any kind of ETA for this?

I will merge it today and send a pull request today or tomorrow.

> 
> I've put these into my ppc-for-2.7 tree, not because I intend to push
> them from there, but so I can do the ppc specific fixups on top of
> them.  I'm hoping these will disappear in a rebase before my next pull
> request.

No problem. Thanks!

-- 
Eduardo