On 03/14/2017 03:37 PM, Jason Wang wrote:
On 2017年03月13日 15:21, Zhang Chen wrote:
On 03/13/2017 03:10 PM, Zhang Chen wrote:
On 03/13/2017 02:28 PM, Jason Wang wrote:
On 2017年03月13日 14:18, Zhang Chen wrote:
Hi~~~ All~
No news for a long time, anyone can give me some comments?
Hi,
A question is why use two kinds of colo-frames? This seems not good
as lots of the code were duplicated.
Because Xen colo-frame based on Xen Remus.
Remus do some job like the migration job in qemu/kvm, and in Xen HVM
we can not do migration in qemu,
So colo-frame code must running in Xen side.
In addition, Xen HVM use qemu to simulation device that Colo-proxy
and Replication can use same one codes in qemu.
Detail:
https://wiki.xenproject.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Thanks
Zhang Chen
Ok, the idea looks ok but let's don't make the code specific to any
hypersior (e.g Xen). Instead, let's define a more generic API like:
1) rename the series to something like "support remote checkpoint",
and mention Xen is the first user
2) do not use something like "COLO_USERSPACE_PROXY_INIT", you can just
use a more generic name like "USERSPACE_PROXY_INIT"
3) instead of using raw strings, you can use soemthing like TLV (or
refer the vhost-user protocol).
Btw, is colo-compare the only user that need to be co-operated with
Xen? If not, better generalize the API.
Yes, only colo-compare.
I got your point, will fix this series in next version.
Thanks
Zhang Chen
Thanks
.
--
Thanks
Zhang Chen
