|
From: | Lei Li |
Subject: | Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM |
Date: | Thu, 03 Oct 2013 21:29:22 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 10/03/2013 06:34 PM, Paolo Bonzini wrote:
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.
If let ram_load take care of checking for RAM_SAVE_FLAG_HOOK, then in unix_accept_incoming_migration(), how to decide which QEMUFile should be opened? Since there would be two types of QEMUFile, one is the original QEMUFile opened by qemu_fopen_socket() for normal Unix migration, the other is opened by qemu_fopen_pipe() for unix-page-flipping migration. Or, were you suggesting replace this qemu_fopen_socket() with the qemu_fopen_pipe(), which also contain the copy of the QEMUFile code for Unix sockets?
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
-- Lei
[Prev in Thread] | Current Thread | [Next in Thread] |