Re: [Qemu-devel] Bug in recent postcopy patch

[Dr. David Alan Gilbert]

* Gary Hook (address@hidden) wrote:
> On 10/30/14, 5:03 AM, "Dr. David Alan Gilbert" <address@hidden> wrote:
> 
> >* Gary Hook (address@hidden) wrote:
> >> *Knock* *knock* *knock* Is this thing on?
> >
> >Yes - but only by luck did I notice this; it's normally better
> >to reply to the thread that posted a patch and cc the authors!
> 
> Well, that depends upon the developers, I think. I was gently admonished
> on another list for addressing a developer (inadvertently) directly. But I
> appreciate your openness, and would not want to abuse your attention.
> 
> >> I applied the 47 pieces of the recent postcopy patch to 2.1.2 and am
> >> poking around. An attempt to migrate results in a NULL pointer
> >>dereference
> >> in savevm.c.  Here is info from gdb:
> >
> >I've not tried migrating with block migration; so can you
> >show the command line you used on qemu and the sequence of commands
> >you used to trigger the migration?
> 
> Yessir.  We invoke the emulator from libvirt. While the problem we are
> dealing with applies to any VM, the one I am working with is invoked
> thusly (edited for readability):
> 
> qemu-system-x86_64 -enable-kvm -name 88dbaf46-4692-4935-bd9d-8d8fac7725a9 \
>       -S -machine pc-0.14,accel=kvm,usb=off -m 1024 -realtime mlock=off \
>       -smp 1,sockets=1,cores=1,threads=1 \
>       -uuid 88dbaf46-4692-4935-bd9d-8d8fac7725a9 -no-user-config -nodefaults \
>       -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/88dbaf46-4692-4935-bd9d-8d
> 8fac7725a9.monitor,server,nowait \
>       -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime \
>       -no-shutdown -boot strict=on -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
>       -drive 
> file=/mnt/store01/virt/88dbaf46-4692-4935-bd9d-8d8fac7725a9.qcow2,if=none,i
> d=drive-virtio-disk0,format=qcow2,cache=writeback \
>       -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virt
> io-disk0,bootindex=1 \
>       -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw \
>       -device 
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 \
>       -netdev tap,fd=29,id=hostnet0 -device
> rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:07:19:5e,bus=pci.0,addr=0x3 \
>       -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 \
>       -vnc 127.0.0.1:0,password -device VGA,id=video0,bus=pci.0,addr=0x2 \
>       -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
>       -msg timestamp=on
> 
> I posted another thread asking about migration failure due to a copy
> taking too long, but got no traction. In the case where the problem raises
> its head we have turned tunneling on. A tiny VM (<2GB in size) migrates
> fine using the same procedure. Again, no shared storage.

Is the guest that doesn't migrate idle or is it busily changing lots of memory?

> >>Q: why is max_size == 0? Does this seem correct?
> >
> >Yes, I think that's normal for the 1st time through the loop; (see
> >migration_thread
> >near the start max_size is initialised to 0).
> 
> Thank you; will do.
> 
> >> 
> >> 
> >> The patches appear to have been fully applied, but it would seem that
> >>the
> >> savevm_block_handlers structure needs to be updated to populate this
> >> field? Which implies that a new function will have to be written?
> >> 
> >> Or, if I have missed the obvious, I would appreciate enlightenment.
> >
> >Simple bug on my part; the line:
> >
> >        if (se->ops->can_postcopy(se->opaque)) {
> >
> >needs to become:
> >        if (se->ops->can_postcopy &&
> >            se->ops->can_postcopy(se->opaque)) {
> 
> I wondered if that were not the case. I will make that change and see what
> happens.
> 
> >Thanks for the report.
> 
> Thank you for your time and ownership.

No problem; note the postcopy code is still quite young, so don't
be too surprised if you hit other issues.

Dave

> 
> Gary
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK