[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 2011-11-24 at 12:09 +0000, Anthony PERARD wrote:
[...]
> 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.

Oh, I didn't realise these were all existing qmp commands, I assumed a
patch adding them was forthcoming. You can ignore most of what I said
then...

> 
> 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,
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.