From: Paolo Bonzini <pbonzini@redhat.com>
To: Lei Li <lilei@linux.vnet.ibm.com>
Cc: aarcange@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org,
mrhines@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com,
anthony@codemonkey.ws, lagarcia@br.ibm.com,
rcj@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM
Date: Thu, 03 Oct 2013 12:34:59 +0200 [thread overview]
Message-ID: <524D4853.5030907@redhat.com> (raw)
In-Reply-To: <524D46E0.7010002@linux.vnet.ibm.com>
Il 03/10/2013 12:28, Lei Li ha scritto:
>
> The load_hook callback is only be called if the RAM_SAVE_FLAG_HOOK is
> received.
> To check this flags, it means there would be a check action first in
> unix_accept_incoming_migration(), like:
>
> f = qemu_fopen_pipe(c, "rb");
> flags = qemu_get_be64(f);
> if (flags == RAM_SAVE_FLAG_HOOK) {
> load_hook();
> ...
> }
>
> Otherwise, the incoming side has no idea whether the special 8-bytes record
> (RAM_SAVE_FLAG_HOOK) is sent.
No, ram_load is taking care of checking for RAM_SAVE_FLAG_HOOK. If
before_iterate writes the 8 bytes (followed by passing the fd for the
pipe's read-side via SCM_RIGHTS), ram_load will call load_hook before it
loads any page and load_hook will fetch the fd.
Subsequent calls to load_hook will match data written by the sender's
save_page hook (so they contain a RAM address, with the 4k page data
sent on the pipe).
Paolo
next prev parent reply other threads:[~2013-10-03 10:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 14:32 [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 1/8] migration-local: add pipe protocol for QEMUFileOps Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 2/8] migration-loca: add qemu_fopen_pipe() Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 3/8] migration-local: add send_pipefd() Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 4/8] migration-local: add recv_pipefd() Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 5/8] QAPI: introduce magration capability unix_page_flipping Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 6/8] migration: add migrate_unix_page_flipping() Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 7/8] migration-unix: side channel support on unix outgoing Lei Li
2013-09-25 14:32 ` [Qemu-devel] [PATCH 8/8] migration-unix: side channel support on unix incoming Lei Li
2013-09-25 15:02 ` [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM Paolo Bonzini
2013-09-26 12:44 ` Lei Li
2013-09-26 12:54 ` Paolo Bonzini
2013-10-03 4:03 ` Lei Li
2013-10-03 8:23 ` Paolo Bonzini
2013-10-03 10:28 ` Lei Li
2013-10-03 10:34 ` Paolo Bonzini [this message]
2013-10-03 13:29 ` Lei Li
2013-10-03 13:34 ` Paolo Bonzini
2013-10-03 13:37 ` Lei Li
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=524D4853.5030907@redhat.com \
--to=pbonzini@redhat.com \
--cc=aarcange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=lagarcia@br.ibm.com \
--cc=lilei@linux.vnet.ibm.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rcj@linux.vnet.ibm.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.