From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45963 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNfRd-0007fZ-7P for qemu-devel@nongnu.org; Wed, 01 Dec 2010 00:41:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNKP6-00035Y-Sk for qemu-devel@nongnu.org; Tue, 30 Nov 2010 02:13:34 -0500 Received: from mail-ww0-f41.google.com ([74.125.82.41]:61751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNKP6-00035G-N1 for qemu-devel@nongnu.org; Tue, 30 Nov 2010 02:13:32 -0500 Received: by wwb28 with SMTP id 28so913544wwb.4 for ; Mon, 29 Nov 2010 23:13:31 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: <4CF3DD61.2010102@codemonkey.ws> References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4CF3D7A0.7010700@redhat.com> <201011291653.42595.paul@codesourcery.com> <4CF3DD61.2010102@codemonkey.ws> Date: Tue, 30 Nov 2010 16:13:30 +0900 Message-ID: Subject: Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2 From: Yoshiaki Tamura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ohmura.kei@lab.ntt.co.jp, mtosatti@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, aliguori@us.ibm.com, Stefan Hajnoczi , dlaor@redhat.com, qemu-devel@nongnu.org, vatsa@linux.vnet.ibm.com, Blue Swirl , Paul Brook , ananth@in.ibm.com, psuriset@linux.vnet.ibm.com, avi@redhat.com 2010/11/30 Anthony Liguori : > On 11/29/2010 10:53 AM, Paul Brook wrote: >>>> >>>> Is this a fair summary: any device that supports live migration workw >>>> under Kemari? >>>> >>> >>> It might be fair summary but practically we barely have live migration >>> working w/o Kemari. In addition, last I checked Kemari needs additional >>> hooks and it will be too hard to keep that out of tree until all device= s >>> get it. >>> >> >> That's not what I've been hearing earlier in this thread. >> The responses from Yoshi indicate that Stefan's summary is correct. =A0i= .e. >> the >> current Kemari implementation may require per-device hooks, but that's a >> bug >> and should be fixed before merging. >> > > It's actually really important that Kemari make use of an intermediate la= yer > such that the hooks can distinguish between a device access and a recursi= ve > access. > > You could s/bdrv_aio_multiwrite/bdrv_aio_multiwrite_internal/g and then > within kemari, s/bdrv_aio_multiwrite_proxy/bdrv_aio_multiwrite/ but I don= 't > think that results in a cleaner interface. > > I don't like the _proxy naming and I think it has led to some confusion. = =A0I > think having a dev_aio_multiwrite interface is a better naming scheme and > ultimately provides a clearer idea of why a separate interface is needed-= -to > distinguish between device accesses and internal accesses. Sorry about the naming. But from the discussion so far, adding an intermediate layer and exporting it to some/all approach needs a strong reason. Kemari itself can be implemented w/ or w/o the intermediate layer, and this makes the discussion toward folding the layer into block/net to be appropriate. I think there are two perspectives to decide which way to go: - What is clean interfaces for upper/lower layer? - If we introduce the intermediate layer, is there anyone who may use now or in the future? If not, it may not be worth to add. Yoshi > > BTW, dev_aio_multiwrite should take a DeviceState * and a BlockDriverStat= e. > > Regards, > > Anthony Liguori > >> Paul >> -- >> To unsubscribe from this list: send the line "unsubscribe kvm" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >> > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >