Re: [Qemu-devel] [PATCH 0/3] COLO-compare: Make COLO-compare support Xen

[Zhang Chen]

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