From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=38301 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PN59h-0004j8-VQ
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 09:56:39 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PN59g-0003ES-M9
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 09:56:37 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:35836)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PN59g-0003Dz-EZ
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 09:56:36 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2
Date: Mon, 29 Nov 2010 14:56:15 +0000
References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp>
	<201011291412.21001.paul@codesourcery.com>
	<AANLkTik4p30oY6rSOZ0gEpsnMAg+A1DAStE5Jq0GtFo_@mail.gmail.com>
In-Reply-To: <AANLkTik4p30oY6rSOZ0gEpsnMAg+A1DAStE5Jq0GtFo_@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201011291456.16360.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
Cc: ohmura.kei@lab.ntt.co.jp, dlaor@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Stefan Hajnoczi <stefanha@gmail.com>, mtosatti@redhat.com, qemu-devel@nongnu.org, vatsa@linux.vnet.ibm.com, Blue Swirl <blauwirbel@gmail.com>, aliguori@us.ibm.com, ananth@in.ibm.com, psuriset@linux.vnet.ibm.com, avi@redhat.com

> > 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.

Paul