All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Alex Williamson <alex.williamson@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 16:15:02 +0300	[thread overview]
Message-ID: <4C56C4D6.4000704@redhat.com> (raw)
In-Reply-To: <1280754720.6598.10.camel@x201>

  On 08/02/2010 04:12 PM, Alex Williamson wrote:
> 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?

Looked in qemu logs, but didn't see it.  Maybe I missed it in the noise, 
or maybe autotest saw SIGCHLD and closed the logging channel.

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

I'll try it manually and see.

-- 
error compiling committee.c: too many arguments to function


WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Alex Williamson <alex.williamson@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 16:15:02 +0300	[thread overview]
Message-ID: <4C56C4D6.4000704@redhat.com> (raw)
In-Reply-To: <1280754720.6598.10.camel@x201>

  On 08/02/2010 04:12 PM, Alex Williamson wrote:
> 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?

Looked in qemu logs, but didn't see it.  Maybe I missed it in the noise, 
or maybe autotest saw SIGCHLD and closed the logging channel.

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

I'll try it manually and see.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2010-08-02 13:15 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
2010-08-02 13:12     ` [Qemu-devel] " Alex Williamson
2010-08-02 13:15     ` Avi Kivity [this message]
2010-08-02 13:15       ` 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=4C56C4D6.4000704@redhat.com \
    --to=avi@redhat.com \
    --cc=alex.williamson@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.