From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46947 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PN6nT-0007uA-M8 for qemu-devel@nongnu.org; Mon, 29 Nov 2010 11:41:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PN6nS-00046J-5S for qemu-devel@nongnu.org; Mon, 29 Nov 2010 11:41:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PN6nR-000463-Tu for qemu-devel@nongnu.org; Mon, 29 Nov 2010 11:41:46 -0500 Message-ID: <4CF3D7A0.7010700@redhat.com> Date: Mon, 29 Nov 2010 18:41:04 +0200 From: Dor Laor 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> <201011291412.21001.paul@codesourcery.com> <201011291456.16360.paul@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: ohmura.kei@lab.ntt.co.jp, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, mtosatti@redhat.com, Yoshiaki Tamura , ananth@in.ibm.com, qemu-devel@nongnu.org, Blue Swirl , Paul Brook , vatsa@linux.vnet.ibm.com, psuriset@linux.vnet.ibm.com, avi@redhat.com On 11/29/2010 06:23 PM, Stefan Hajnoczi wrote: > On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura > wrote: >> 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 some >>>>> fairly specific QA testing. I'd rather not get into that game. The >>>>> 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. My plan would >>>> be to initially start from a subset of devices, and gradually >>>> grow the number of devices that Kemari works with. While this >>>> process, it'll include what you said above, file a but and/or fix >>>> the code. Am I missing what you're saying? >>> >>> My point is that the whitelist shouldn't exist at all. Devices either support >>> migration or they don't. Having 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. > > (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