From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=39443 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PN3du-0000IW-J0
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 08:19:45 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PN3ds-0005AY-Qq
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 08:19:42 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:50699)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PN3ds-0005AQ-Ip
	for qemu-devel@nongnu.org; Mon, 29 Nov 2010 08:19:40 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2
Date: Mon, 29 Nov 2010 13:19:20 +0000
References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp>
	<201011291300.43082.paul@codesourcery.com>
	<AANLkTiksE9L-KOVwPBjZeV9qCg-AcbUx9Ko3NmW26Qaf@mail.gmail.com>
In-Reply-To: <AANLkTiksE9L-KOVwPBjZeV9qCg-AcbUx9Ko3NmW26Qaf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201011291319.20514.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: qemu-devel@nongnu.org
Cc: ohmura.kei@lab.ntt.co.jp, mtosatti@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Stefan Hajnoczi <stefanha@gmail.com>, dlaor@redhat.com, Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>, vatsa@linux.vnet.ibm.com, Blue Swirl <blauwirbel@gmail.com>, aliguori@us.ibm.com, avi@redhat.com, psuriset@linux.vnet.ibm.com, ananth@in.ibm.com

> 2010/11/29 Paul Brook <paul@codesourcery.com>:
> >> >> Could you formulate the constraints so developers are aware of them
> >> >> in the future and can protect the codebase.  How about expanding the
> >> >> Kemari wiki pages?
> >> > 
> >> > If you like the idea above, I'm happy to make the list also on
> >> > the wiki page.
> >> 
> >> Here's a different question: what requirements must an emulated device
> >> meet in order to be added to the Kemari supported whitelist?  That's
> >> what I want to know so that I don't break existing devices and can add
> >> new devices that work with Kemari :).
> > 
> > Why isn't it completely device agnostic? i.e. if a device has to care
> > about Kemari at all (of vice-versa) then IMO you're doing it wrong. The
> > whole point of the internal block/net APIs is that they isolate the host
> > implementation details from the device emulation.
> 
> You're right "theoretically".  But what I've learned so far,
> there are cases like virtio-net and e1000 woks but virtio-blk
> doesn't.  "Theoretically", any emulated device should be able to
> get into the whitelist if the event-tap is properly implemented
> but sometimes it doesn't seem to be that simple.
> 
> To answer Stefan's question, there shouldn't be any requirement
> for a device, but must be tested with Kemari.  If it doesn't work
> correctly, the problems must be fixed before adding to the list.

What exactly are the problems? Is this a device bus of a Kemari bug?
If it's the former then that implies you're imposing additional requirements 
that weren't previously part of the API.  If the latter, then it's a bug like 
any other.

Paul