[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |