From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3eIY-0002gl-HL for qemu-devel@nongnu.org; Fri, 20 May 2016 02:52:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b3eIU-0006qQ-Bw for qemu-devel@nongnu.org; Fri, 20 May 2016 02:52:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b3eIU-0006qK-3R for qemu-devel@nongnu.org; Fri, 20 May 2016 02:52:34 -0400 Date: Fri, 20 May 2016 14:52:32 +0800 From: Fam Zheng Message-ID: <20160520065232.GB28421@ad.usersys.redhat.com> References: <5721D21C.6070202@cn.fujitsu.com> <5722C0D6.8080805@redhat.com> <572C2EB4.1090005@cn.fujitsu.com> <572C3BAF.5080106@redhat.com> <57306B3C.5090000@cn.fujitsu.com> <5734275C.8070406@cn.fujitsu.com> <5734385B.6040004@redhat.com> <57343BD0.5060206@cn.fujitsu.com> <57354E7C.6040408@redhat.com> <573E7A94.8090306@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <573E7A94.8090306@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH V3 1/4] colo-compare: introduce colo compare initlization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang Cc: Zhang Chen , qemu devel , zhanghailiang , Li Zhijian , Gui jianfeng , "eddie.dong" , "Dr. David Alan Gilbert" , Amit Shah , Yang Hongyang On Fri, 05/20 10:46, Jason Wang wrote: >=20 >=20 > On 2016=E5=B9=B405=E6=9C=8813=E6=97=A5 11:48, Jason Wang wrote: > >=20 > >=20 > > On 2016=E5=B9=B405=E6=9C=8812=E6=97=A5 16:16, Zhang Chen wrote: > > >=20 > > >=20 > > > On 05/12/2016 04:01 PM, Jason Wang wrote: > > > >=20 > > > >=20 > > > > On 2016=E5=B9=B405=E6=9C=8812=E6=97=A5 14:49, Zhang Chen wrote: > > > > >=20 > > > > >=20 > > > > > On 05/09/2016 06:49 PM, Zhang Chen wrote: > > > > > >=20 > > > > > > > + > > > > > > > + s->chr_sec_in =3D qemu_chr_find(s->sec_indev); > > > > > > > + if (s->chr_sec_in =3D=3D NULL) { > > > > > > > + error_setg(errp, "Secondary IN Device '%s' not fou= nd", > > > > > > > + s->sec_indev); > > > > > > > + return; > > > > > > > + } > > > > > > > + > > > > > > > + s->chr_out =3D qemu_chr_find(s->outdev); > > > > > > > + if (s->chr_out =3D=3D NULL) { > > > > > > > + error_setg(errp, "OUT Device '%s' not found", s->o= utdev); > > > > > > > + return; > > > > > > > + } > > > > > > > + > > > > > > > + qemu_chr_fe_claim_no_fail(s->chr_pri_in); > > > > > > > + qemu_chr_add_handlers(s->chr_pri_in, compare_chr_can_r= ead, > > > > > > > + compare_pri_chr_in, NULL, s); > > > > > > > + > > > > > > > + qemu_chr_fe_claim_no_fail(s->chr_sec_in); > > > > > > > + qemu_chr_add_handlers(s->chr_sec_in, compare_chr_can_r= ead, > > > > > > > + compare_sec_chr_in, NULL, s); > > > > > > > + > > > > > > > > > > > > > Btw, what's the reason of > > > > > > > > > > > > > handling this in main loop? > > > > > > > > > > > > > I thought it > > > > > > > > > > > > > would > > > > > > > > > > > > > be better to do this in colo > > > > > > > > > > > > > thread? Otherwise, you need > > > > > > > > > > > > > lots of > > > > > > > > > > > > > extra > > > > > > > > > > > > > synchronizations? > > > > > > > > > > > > Do you mean we should > > > > > > > > > > > > start/stop/do checkpoint it by > > > > > > > > > > > > colo-frame? > > > > > > > > > > > I mean we probably want to handle > > > > > > > > > > > pri_in and sec_in in colo compare > > > > > > > > > > > thread. Through this way, there's no > > > > > > > > > > > need for extra synchronization > > > > > > > > > > > with > > > > > > > > > > > main loop. > > > > > > > > > > I get your point, but how to do this. > > > > > > > > > > Now, we use qemu_chr_add_handlers to do this job. > > > > > > > > > You probably want to start a new main loop > > > > > > > > > in colo comparing thread. > > > > > > > >=20 > > > > > > > > IIUC, do you mean > > > > > > > > - remove char device read_handler > > > > > > > >=20 > > > > > > > > =E2=86=93at colo comparing thread=E2=86=93 > > > > > > > > while (true) { > > > > > > > > - blocking read packet from char device with select(2)/po= ll(2)... > > > > > > > > - compare packet > > > > > > > > } > > > > > > > Yes, something like this. > > > > > > >=20 > > > > > >=20 > > > > > > But remove qemu_chr_add_handlers I can't get fd to select/pol= l. > > > > > >=20 > > > > > > How to get fd from all kinds of chardev? > > > > > >=20 > > > > >=20 > > > > > Hi~ jason. > > > > >=20 > > > > > If we use chardev socket the fd save in QIOChannelSocket. > > > > >=20 > > > > > and if we use chardev file the fd save in QIOChannelFile. > > > > >=20 > > > > > Have any common method to get fd? > > > >=20 > > > > I'm not sure I get the question. But you probably can call > > > > qemu_chr_add_handlers() in colo comparing thread to solve this I > > > > think? > > > >=20 > > >=20 > > > I have tested call qemu_chr_add_handlers() in colo comparing thread= , > > > but when data come, > > > the handler always running in main loop. > > >=20 > > > Thanks > > > Zhang Chen > >=20 > > Cc Amit for the help. > >=20 > > Amit, we want to poll and handle chardev in another thread other than > > main loop. But looks like qemu_chr_add_handlers() can only work for > > default context other than thread default context. Any other solution > > for this? > >=20 > > Thanks > >=20 >=20 > Cc Fam for more thought. >=20 Unfortunately QIOChannel in chardev uses GSource, so there is no easy way= to move that to another thread, at least I don't think any code in QEMU has = ever tried. One possibility is in the colo compare thread, call g_main_context_push_thread_default() before setting up the chr handler, b= ut I'm not sure how well that would work. Fam