From: Alex Williamson <alex.williamson@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
KVM list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>
Subject: Re: Migration issues in qemu.git
Date: Mon, 02 Aug 2010 07:12:00 -0600 [thread overview]
Message-ID: <1280754720.6598.10.camel@x201> (raw)
In-Reply-To: <4C5692FD.80808@redhat.com>
On Mon, 2010-08-02 at 12:42 +0300, Avi Kivity wrote:
> On 08/02/2010 12:06 PM, Avi Kivity wrote:
> > I'm hitting some migration issues merging qemu.git into qemu-kvm.git:
> >
> > 1. Crash in mig_cancel test:
> >
> > (gdb) bt
> > #0 0x0000003a91c83dbb in memcpy () from /lib64/libc.so.6
> > #1 0x000000000049c2ff in qemu_get_buffer (f=0x302d870, buf=<value
> > optimized out>, size1=4096) at /usr/include/bits/string3.h:52
> > #2 0x0000000000409464 in ram_load (f=0x302d870, opaque=<value
> > optimized out>, version_id=4) at
> > /build/home/tlv/akivity/qemu-kvm/arch_init.c:407
> > #3 0x000000000049cb4c in qemu_loadvm_state (f=0x302d870) at
> > savevm.c:1708
> > #4 0x0000000000494169 in process_incoming_migration (f=<value
> > optimized out>) at migration.c:63
> > #5 0x0000000000494517 in tcp_accept_incoming_migration (opaque=<value
> > optimized out>) at migration-tcp.c:163
> > #6 0x000000000041b67e in main_loop_wait (nonblocking=<value optimized
> > out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1300
> > #7 0x00000000004314e7 in kvm_main_loop () at
> > /build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1710
> > #8 0x000000000041c67f in main_loop (argc=<value optimized out>,
> > argv=<value optimized out>, envp=<value optimized out>)
> > at /build/home/tlv/akivity/qemu-kvm/vl.c:1340
> > #9 main (argc=<value optimized out>, argv=<value optimized out>,
> > envp=<value optimized out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:3069
> >
> > This is on the incoming side so the test completes successfully, only
> > leaving a core dump to fill my disks.
>
>
> This appears to be
>
> > static inline void *host_from_stream_offset(QEMUFile *f,
> > ram_addr_t offset,
> > int flags)
> > {
> > static RAMBlock *block = NULL;
> > char id[256];
> > uint8_t len;
> >
> > if (flags & RAM_SAVE_FLAG_CONTINUE) {
> > if (!block) {
> > fprintf(stderr, "Ack, bad migration stream!\n");
> > return NULL;
> > }
> >
> > return block->host + offset;
> > }
>
> with block == NULL, if my gdb-fu got a static variable in an inlined
> function examined correctly.
If block == NULL, are you getting the fprintf?
> I don't see any special reason for block to be NULL on a cancelled
> migration. Though perhaps the incoming stream was terminated without us
> noticing, and we're migrating from some random buffer and confusing the
> code?
Yeah, I don't understand that either, block == NULL should only be an
initial state, once we've seen a block it shouldn't happen. Does this
patch solve anything:
http://lists.nongnu.org/archive/html/qemu-devel/2010-07/msg01114.html
I could see this fixing it if the migration was re-attempted after the
cancel.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
KVM list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>
Subject: [Qemu-devel] Re: Migration issues in qemu.git
Date: Mon, 02 Aug 2010 07:12:00 -0600 [thread overview]
Message-ID: <1280754720.6598.10.camel@x201> (raw)
In-Reply-To: <4C5692FD.80808@redhat.com>
On Mon, 2010-08-02 at 12:42 +0300, Avi Kivity wrote:
> On 08/02/2010 12:06 PM, Avi Kivity wrote:
> > I'm hitting some migration issues merging qemu.git into qemu-kvm.git:
> >
> > 1. Crash in mig_cancel test:
> >
> > (gdb) bt
> > #0 0x0000003a91c83dbb in memcpy () from /lib64/libc.so.6
> > #1 0x000000000049c2ff in qemu_get_buffer (f=0x302d870, buf=<value
> > optimized out>, size1=4096) at /usr/include/bits/string3.h:52
> > #2 0x0000000000409464 in ram_load (f=0x302d870, opaque=<value
> > optimized out>, version_id=4) at
> > /build/home/tlv/akivity/qemu-kvm/arch_init.c:407
> > #3 0x000000000049cb4c in qemu_loadvm_state (f=0x302d870) at
> > savevm.c:1708
> > #4 0x0000000000494169 in process_incoming_migration (f=<value
> > optimized out>) at migration.c:63
> > #5 0x0000000000494517 in tcp_accept_incoming_migration (opaque=<value
> > optimized out>) at migration-tcp.c:163
> > #6 0x000000000041b67e in main_loop_wait (nonblocking=<value optimized
> > out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1300
> > #7 0x00000000004314e7 in kvm_main_loop () at
> > /build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1710
> > #8 0x000000000041c67f in main_loop (argc=<value optimized out>,
> > argv=<value optimized out>, envp=<value optimized out>)
> > at /build/home/tlv/akivity/qemu-kvm/vl.c:1340
> > #9 main (argc=<value optimized out>, argv=<value optimized out>,
> > envp=<value optimized out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:3069
> >
> > This is on the incoming side so the test completes successfully, only
> > leaving a core dump to fill my disks.
>
>
> This appears to be
>
> > static inline void *host_from_stream_offset(QEMUFile *f,
> > ram_addr_t offset,
> > int flags)
> > {
> > static RAMBlock *block = NULL;
> > char id[256];
> > uint8_t len;
> >
> > if (flags & RAM_SAVE_FLAG_CONTINUE) {
> > if (!block) {
> > fprintf(stderr, "Ack, bad migration stream!\n");
> > return NULL;
> > }
> >
> > return block->host + offset;
> > }
>
> with block == NULL, if my gdb-fu got a static variable in an inlined
> function examined correctly.
If block == NULL, are you getting the fprintf?
> I don't see any special reason for block to be NULL on a cancelled
> migration. Though perhaps the incoming stream was terminated without us
> noticing, and we're migrating from some random buffer and confusing the
> code?
Yeah, I don't understand that either, block == NULL should only be an
initial state, once we've seen a block it shouldn't happen. Does this
patch solve anything:
http://lists.nongnu.org/archive/html/qemu-devel/2010-07/msg01114.html
I could see this fixing it if the migration was re-attempted after the
cancel.
Alex
next prev parent reply other threads:[~2010-08-02 13:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 9:06 Migration issues in qemu.git Avi Kivity
2010-08-02 9:06 ` [Qemu-devel] " Avi Kivity
2010-08-02 9:42 ` Avi Kivity
2010-08-02 9:42 ` [Qemu-devel] " Avi Kivity
2010-08-02 13:12 ` Alex Williamson [this message]
2010-08-02 13:12 ` Alex Williamson
2010-08-02 13:15 ` Avi Kivity
2010-08-02 13:15 ` [Qemu-devel] " Avi Kivity
2010-08-02 13:15 ` Avi Kivity
2010-08-02 13:15 ` [Qemu-devel] " Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1280754720.6598.10.camel@x201 \
--to=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.