Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Thu, Nov 24, 2011 at 09:22, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2011-11-23 at 17:40 +0000, Anthony PERARD wrote:
>> Hi all,
>>
>> This patch series introduce migration with QEMU upstream.
>>
>> A patch series for QEMU will be sent later meant to "fix" the default 
>> behavior
>> of QEMU during save/restore.
>>
>> There is two new QMP commands implemented:
>> Â - getfd: This give a file descriptor to QEMU through the unix socket.
>
> This sounds more like a setfd command.

Well, it's the name of the QMP command. I just respect the
"convention" I have in the rest of the file that is
/(libxl__)?qmp_(?<command_name>.+)/


>> Â - migration: This ask QEMU to save its states in a fd previously sent.
>
> Why can the fd not be included in this message directly?

The migrate command only accept "fd:namedfd" as output (among other
way). And to have a named fd, we have to call "getfd" fist. But here,
I do both with one call from the wild.

> How is a given {s,g}etfd call associated with the migration command?

libxl__qmp_migrate will call a static function qmp_getfd(fd, "migration-fd")

> What happens if some other command also wants to receive an fd in the future?

The futur command can just call the qmp_getfd function, or we can
export qmp_getfd.

> I presume that a bunch of this will become Âmore obvious when the qemu
> side is posted, there's a qemu protocol spec in that right?

Mmh, not really, there is nothing to had in QEMU side. getfd and
migrate are both QMP command. You can look in the file qmp-commands.hx
in QEMU for the command migrate and getfd; and look in the file
docs/migration.txt to know wich "Types of migration" QEMU use.

The QEMU patch series I'm about to send is just a "fix" for the Xen case:
 - do not save the RAM.
 - at restore time, do not try to "allocate" (populate_physmap) memory
that should already be allocated, and access to the right guest
address in case this one have been "moved" (true for the VideoRAM)
("moved" using add_to_physmap).

>> In order to call "getfd", an alternative qmp_send have been implemented in
>> libxl.
>
> You could also have added optional msg_control{len} parameters to the
> existing command. I don't know if that is better though.

Well, this will be an extra parameter that will be used in only one
case (I think). And this parameter will be a bit obscure. So, probably
both are good. Also, the code that prepare the message (string) to be
sent is in a separate function now, so both qmp_send and qmp_send_fd
do not have anything in common (almost).

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel