From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39757 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNfYz-0004CM-SZ for qemu-devel@nongnu.org; Wed, 01 Dec 2010 00:49:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNJwc-0006uh-7n for qemu-devel@nongnu.org; Tue, 30 Nov 2010 01:44:07 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:61611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNJwc-0006so-2A for qemu-devel@nongnu.org; Tue, 30 Nov 2010 01:44:06 -0500 Received: by wyg36 with SMTP id 36so5262613wyg.4 for ; Mon, 29 Nov 2010 22:43:55 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: <4CF3D7A0.7010700@redhat.com> References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <201011291412.21001.paul@codesourcery.com> <201011291456.16360.paul@codesourcery.com> <4CF3D7A0.7010700@redhat.com> Date: Tue, 30 Nov 2010 15:43:54 +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: dlaor@redhat.com Cc: ohmura.kei@lab.ntt.co.jp, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Stefan Hajnoczi , mtosatti@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, Blue Swirl , Paul Brook , vatsa@linux.vnet.ibm.com, avi@redhat.com, psuriset@linux.vnet.ibm.com, ananth@in.ibm.com 2010/11/30 Dor Laor : > On 11/29/2010 06:23 PM, Stefan Hajnoczi wrote: >> >> On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura >> =A0wrote: >>> >>> 2010/11/29 Paul Brook: >>>>>> >>>>>> If devices incorrectly claim support for live migration, then that >>>>>> should >>>>>> also be fixed, either by removing the broken code or by making it >>>>>> work. >>>>> >>>>> I totally agree with you. >>>>> >>>>>> AFAICT your current proposal is just feeding back the results of som= e >>>>>> fairly specific QA testing. =A0I'd rather not get into that game. = =A0The >>>>>> correct response in the context of upstream development is to file a >>>>>> bug >>>>>> and/or fix the code. We already have config files that allow third >>>>>> party >>>>>> packagers to remove devices they don't want to support. >>>>> >>>>> Sorry, I didn't get what you're trying to tell me. =A0My plan would >>>>> be to initially start from a subset of devices, and gradually >>>>> grow the number of devices that Kemari works with. =A0While this >>>>> process, it'll include what you said above, file a but and/or fix >>>>> the code. =A0Am I missing what you're saying? >>>> >>>> My point is that the whitelist shouldn't exist at all. =A0Devices eith= er >>>> support >>>> migration or they don't. =A0Having some sort of separate whitelist is = the >>>> wrong >>>> way to determine which devices support migration. >>> >>> Alright! >>> >>> Then if a user encounters a problem with Kemari, we'll fix Kemari >>> or the devices or both. Correct? >> >> 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. IIUC, the additional hook you're mentioning is the hack for virtio. Michael has commented on it, I hope his patch make the hack unnecessary. Yoshi > >> >> (If such a device does not work under Kemari then this is a bug that >> needs to be fixed in live migration, Kemari, or the device.) >> >> Stefan > > >