From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: quintela@redhat.com
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] semantics of qemu_peek_buffer ?
Date: Fri, 14 Mar 2014 20:17:19 +0000 [thread overview]
Message-ID: <20140314201719.GJ2513@work-vm> (raw)
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
next reply other threads:[~2014-03-14 20:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 20:17 Dr. David Alan Gilbert [this message]
2014-03-18 12:39 ` [Qemu-devel] semantics of qemu_peek_buffer ? Juan Quintela
2014-03-18 13:08 ` Dr. David Alan Gilbert
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=20140314201719.GJ2513@work-vm \
--to=dgilbert@redhat.com \
--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.