From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52462 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PN65o-0006qY-VQ
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 10:56:41 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PN65n-000260-Rs
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 10:56:40 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:50126)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PN65n-00025n-KD
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 10:56:39 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2
Date: Mon, 29 Nov 2010 15:56:18 +0000
References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp>
	<201011291456.16360.paul@codesourcery.com>
	<AANLkTimKxmzUWQqgF=dMn=A_j5rE=JvoqiPzmA=nHx3M@mail.gmail.com>
In-Reply-To: <AANLkTimKxmzUWQqgF=dMn=A_j5rE=JvoqiPzmA=nHx3M@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201011291556.18718.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

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

Correct.

Paul