[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for R
From: |
Lei Li |
Subject: |
Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM |
Date: |
Thu, 03 Oct 2013 18:28:48 +0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 10/03/2013 04:23 PM, Paolo Bonzini wrote:
Il 03/10/2013 06:03, Lei Li ha scritto:
Hi Paolo,
When debugging the code, I realized that this problem might still
exist. In the incoming part, it will qemu_fopen_pipe() in
unix_accept_incoming_migration first to enable the load_hook
callback, the check action of this RAM_SAVE_FLAG_HOOK flags would
lead to 8 bytes taken. Turns out, it will break normal unix
migration (without unix-page-flipping), because no matter normal unix
migration or unix-page-flipping migration, the incoming side has to
check this 8-byes flags first to decide whether the load_hook is
called, and normal unix migration did not send this 8-byte flags.
Why is the load_hook callback being called at all without page flipping?
Without page flipping, the before_iterate and save_page hook will
return immediately (or depending on your code they may never be called),
so the RAM_SAVE_FLAG_HOOK will never be written to the Unix socket.
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.
In unix-page-flipping migration, it is OK. Without page flipping, since the
RAM_SAVE_FLAG_HOOK is not be written to the Unix socket, but the incoming
side will still check it, that will lead to the unexpected 8-bytes taken.
If the logic and the way to deal with it above is correct according to your
suggestion, how about:
1) Use another Unix socket to deal with this flags and pipe fd passing.
or 2) Use a new prefix URI for the incoming.
I wonder if I didn't understand your suggestion correctly?
Perhaps you want to discuss this tomorrow morning on #qemu?
I joined the #qemu channel just now, seems you were not there.
I guess it's your lunch time right now. :)
Paolo
--
Lei