Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM

[Lei Li <lilei@linux.vnet.ibm.com>]

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