From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOYXq-00023J-TB for qemu-devel@nongnu.org; Fri, 14 Mar 2014 16:17:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOYXk-0002BZ-QS for qemu-devel@nongnu.org; Fri, 14 Mar 2014 16:17:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOYXk-0002BM-JS for qemu-devel@nongnu.org; Fri, 14 Mar 2014 16:17:24 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2EKHNBP024742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Mar 2014 16:17:23 -0400 Date: Fri, 14 Mar 2014 20:17:19 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20140314201719.GJ2513@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] semantics of qemu_peek_buffer ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: qemu-devel@nongnu.org Hi Juan, What are the semantics of 'qemu_peek_buffer'? - is it supposed to guarantee (if there are no errors) that it will read 'size' bytes? (i.e. it should block) There are currently two users of it: * qemu_read_buffer which spins filling it's buffer up with repeated calls to qemu_peek_buffer * vmstate_subsection_load that returns if the size read doesn't match what it was expecting I can't see how both of them can be right. The problem I'm seeing is that in my world I've got a qemu_peek_buffer of 8 bytes, and with a repeated virt-test local tcp migration it's failing about 1 in 8 times; here is some debug: 19:51:15 INFO | [qemu output] qemu_peek_buffer refill case (pre); size=8 offset=0 index=32764 pending=4 buf_index=32764 buf_size=32768 pos=23302795 19:51:15 INFO | [qemu output] qemu_fill_buffer got 1 19:51:15 INFO | [qemu output] qemu_peek_buffer refill case (post); size=8 offset=0 index=0 pending=5 buf_index=0 buf_size=5 pos=23302796 19:51:15 INFO | [qemu output] qemu_peek_buffer (size>pending); size=8 offset=0 index=0 pending=5 buf_index=0 buf_size=5 pos=23302796 i.e. I asked for 8 bytes, there were 4 in the buffer, it called fill buffer, which got one more byte, and thus it returned me 5. I think what vmstate_subsection_load wants (and what I want) is something like qemu_read_buffer but which doesn't advance it's pointer, i.e. to read a header, decide it's not for me and let the next function along use it. vmstate_subsection_load doesn't look like it flags an error if it doesn't read enough; I guess the effect will be just to fail to load a migration in some interesting way. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK