From patchwork Mon Apr 17 11:04:12 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Zhanghailiang X-Patchwork-Id: 9683725 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E252B600F6 for ; Mon, 17 Apr 2017 11:07:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D7B4C2521E for ; Mon, 17 Apr 2017 11:07:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CA82225404; Mon, 17 Apr 2017 11:07:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 015A52521E for ; Mon, 17 Apr 2017 11:07:15 +0000 (UTC) Received: from localhost ([::1]:35895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d04V0-0003jU-Kj for patchwork-qemu-devel@patchwork.kernel.org; Mon, 17 Apr 2017 07:07:14 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d04T2-00038e-8Z for qemu-devel@nongnu.org; Mon, 17 Apr 2017 07:05:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d04Sz-0004yM-3T for qemu-devel@nongnu.org; Mon, 17 Apr 2017 07:05:12 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:3378 helo=dggrg03-dlp.huawei.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1d04Sy-0004oN-Hn for qemu-devel@nongnu.org; Mon, 17 Apr 2017 07:05:09 -0400 Received: from 172.30.72.56 (EHLO DGGEML404-HUB.china.huawei.com) ([172.30.72.56]) by dggrg03-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id ALZ38923; Mon, 17 Apr 2017 19:04:42 +0800 (CST) Received: from [127.0.0.1] (10.177.24.212) by DGGEML404-HUB.china.huawei.com (10.3.17.39) with Microsoft SMTP Server id 14.3.301.0; Mon, 17 Apr 2017 19:04:32 +0800 To: Jason Wang , Zhang Chen , References: <1487734936-43472-1-git-send-email-zhang.zhanghailiang@huawei.com> <1487734936-43472-3-git-send-email-zhang.zhanghailiang@huawei.com> <134776c2-a85d-d06f-5f98-2e664f9c8ca9@cn.fujitsu.com> <58F06AA1.2010301@huawei.com> <9b42232a-e86f-2d61-7987-7a0559d6f705@redhat.com> From: Hailiang Zhang Message-ID: <58F4A12C.5070404@huawei.com> Date: Mon, 17 Apr 2017 19:04:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <9b42232a-e86f-2d61-7987-7a0559d6f705@redhat.com> X-Originating-IP: [10.177.24.212] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58F4A14B.00E5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 38c25ac83aae07554862a5e85926b63e X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 45.249.212.189 Subject: Re: [Qemu-devel] [PATCH 02/15] colo-compare: implement the process of checkpoint X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: xuquan8@huawei.com, xiecl.fnst@cn.fujitsu.com, dgilbert@redhat.com, lizhijian@cn.fujitsu.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hi Jason, On 2017/4/14 14:38, Jason Wang wrote: > > On 2017年04月14日 14:22, Hailiang Zhang wrote: >> Hi Jason, >> >> On 2017/4/14 13:57, Jason Wang wrote: >>> On 2017年02月22日 17:31, Zhang Chen wrote: >>>> On 02/22/2017 11:42 AM, zhanghailiang wrote: >>>>> While do checkpoint, we need to flush all the unhandled packets, >>>>> By using the filter notifier mechanism, we can easily to notify >>>>> every compare object to do this process, which runs inside >>>>> of compare threads as a coroutine. >>>> Hi~ Jason and Hailiang. >>>> >>>> I will send a patch set later about colo-compare notify mechanism for >>>> Xen like this patch. >>>> I want to add a new chardev socket way in colo-comapre connect to Xen >>>> colo, for notify >>>> checkpoint or failover, Because We have no choice to use this way >>>> communicate with Xen codes. >>>> That's means we will have two notify mechanism. >>>> What do you think about this? >>>> >>>> >>>> Thanks >>>> Zhang Chen >>> I was thinking the possibility of using similar way to for colo compare. >>> E.g can we use socket? This can saves duplicated codes more or less. >> Since there are too many sockets used by filter and COLO, (Two unix >> sockets and two >> tcp sockets for each vNIC), I don't want to introduce more ;) , but >> i'm not sure if it is >> possible to make it more flexible and optional, abstract these >> duplicated codes, >> pass the opened fd (No matter eventfd or socket fd ) as parameter, for >> example. >> Is this way acceptable ? >> >> Thanks, >> Hailiang > Yes, that's kind of what I want. We don't want to use two message > format. Passing a opened fd need management support, we still need a > fallback if there's no management on top. For qemu/kvm, we can do all > stuffs transparent to the cli by e.g socketpair() or others, but the key > is to have a unified message format. After a deeper investigation, i think we can re-use most codes, since there is no existing way to notify xen (no ?), we still needs notify chardev socket (Be used to notify xen, it is optional.) (http://patchwork.ozlabs.org/patch/733431/ "COLO-compare: Add Xen notify chardev socket handler frame") Besides, there is an existing qmp comand 'xen-colo-do-checkpoint', we can re-use it to notify colo-compare objects and other filter objects to do checkpoint, for the opposite direction, we use the notify chardev socket (Only for xen). So the codes will be like: How about this scenario ？ > Thoughts? > > Thanks > >>> Thanks >>> >>> >>> . >>> >> > > . > diff --git a/migration/colo.c b/migration/colo.c index 91da936..813c281 100644 --- a/migration/colo.c +++ b/migration/colo.c @@ -224,7 +224,19 @@ ReplicationStatus *qmp_query_xen_replication_status(Error **errp) void qmp_xen_colo_do_checkpoint(Error **errp) { + Error *local_err = NULL; + replication_do_checkpoint_all(errp); + /* Notify colo-compare and other filters to do checkpoint */ + colo_notify_compares_event(NULL, COLO_CHECKPOINT, &local_err); + if (local_err) { + error_propagate(errp, local_err); + return; + } + colo_notify_filters_event(COLO_CHECKPOINT, &local_err); + if (local_err) { + error_propagate(errp, local_err); + } } static void colo_send_message(QEMUFile *f, COLOMessage msg, diff --git a/net/colo-compare.c b/net/colo-compare.c index 24e13f0..de975c5 100644 --- a/net/colo-compare.c +++ b/net/colo-compare.c @@ -391,6 +391,9 @@ static void colo_compare_inconsistent_notify(void) { notifier_list_notify(&colo_compare_notifiers, migrate_get_current()); + if (s->notify_dev) { + /* Do something, notify remote side through notify dev */ + } } void colo_compare_register_notifier(Notifier *notify)