From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49405 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PN7c1-0003r0-3Q for qemu-devel@nongnu.org; Mon, 29 Nov 2010 12:34:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PN7bz-00072e-EA for qemu-devel@nongnu.org; Mon, 29 Nov 2010 12:34:01 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:64662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PN7bz-00072a-Af for qemu-devel@nongnu.org; Mon, 29 Nov 2010 12:33:59 -0500 Received: by qwf7 with SMTP id 7so15295qwf.4 for ; Mon, 29 Nov 2010 09:33:58 -0800 (PST) Message-ID: <4CF3E401.2000801@codemonkey.ws> Date: Mon, 29 Nov 2010 11:33:53 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2 References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <201011291653.42595.paul@codesourcery.com> <4CF3DD61.2010102@codemonkey.ws> <201011291718.42500.paul@codesourcery.com> In-Reply-To: <201011291718.42500.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: ohmura.kei@lab.ntt.co.jp, dlaor@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Stefan Hajnoczi , mtosatti@redhat.com, qemu-devel@nongnu.org, Yoshiaki Tamura , Blue Swirl , aliguori@us.ibm.com, vatsa@linux.vnet.ibm.com, avi@redhat.com, psuriset@linux.vnet.ibm.com, ananth@in.ibm.com On 11/29/2010 11:18 AM, Paul Brook wrote: >> 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 devices >>>> 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. i.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 >> layer such that the hooks can distinguish between a device access and a >> recursive access. >> > I'm failing to understand how this is anything other than running sed over > block/*.c (or hw/*.c, depending whether you choose to rename the internal or > external API). > You're right, it's not a big deal, and requiring everything in hw use the new interface is not a bad idea. If a device doesn't work with Kemari, that's okay as long as the non-Kemari case is essentially a nop. Regards, Anthony Liguori > Paul >