From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 COLOPre 19/26] libxc/migration: Specification update for DIRTY_BITMAP records Date: Tue, 30 Jun 2015 11:24:58 +0100 Message-ID: <1435659898.21469.79.camel@citrix.com> References: <1435213552-10556-1-git-send-email-yanghy@cn.fujitsu.com> <1435213552-10556-20-git-send-email-yanghy@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1435213552-10556-20-git-send-email-yanghy@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Yang Hongyang Cc: wei.liu2@citrix.com, wency@cn.fujitsu.com, andrew.cooper3@citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, rshriram@cs.ubc.ca, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Thu, 2015-06-25 at 14:25 +0800, Yang Hongyang wrote: > Used by secondary to send it's dirty bitmap to primary under COLO. This is the backchannel, right? It seems to me that this ought to be described more clearly as a separate stream in the opposite direction, rather than looking like just another record in the forward channel. Does the back channel not also need some sort of negotiation phase where we check both ends are compatible (i.e. like the forward channel's header). This might be easier than with the forward channel since you might assert that the versions must match exactly for COLO to be possible, that might not be true of some potential future user of the backchannel though.