From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33734 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PN3zT-0007uR-PG for qemu-devel@nongnu.org; Mon, 29 Nov 2010 08:42:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PN3zP-0002n8-W8 for qemu-devel@nongnu.org; Mon, 29 Nov 2010 08:41:59 -0500 Received: from mail-ey0-f173.google.com ([209.85.215.173]:46807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PN3zP-0002mS-QI for qemu-devel@nongnu.org; Mon, 29 Nov 2010 08:41:55 -0500 Received: by eya25 with SMTP id 25so2123139eya.4 for ; Mon, 29 Nov 2010 05:41:55 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: <201011291319.20514.paul@codesourcery.com> References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <201011291300.43082.paul@codesourcery.com> <201011291319.20514.paul@codesourcery.com> Date: Mon, 29 Nov 2010 22:41:53 +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: Paul Brook Cc: ohmura.kei@lab.ntt.co.jp, mtosatti@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Stefan Hajnoczi , dlaor@redhat.com, qemu-devel@nongnu.org, vatsa@linux.vnet.ibm.com, Blue Swirl , aliguori@us.ibm.com, avi@redhat.com, psuriset@linux.vnet.ibm.com, ananth@in.ibm.com 2010/11/29 Paul Brook : >> 2010/11/29 Paul Brook : >> >> >> Could you formulate the constraints so developers are aware of the= m >> >> >> in the future and can protect the codebase. =A0How 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 devic= e >> >> meet in order to be added to the Kemari supported whitelist? =A0That'= s >> >> what I want to know so that I don't break existing devices and can ad= d >> >> 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. Th= e >> > whole point of the internal block/net APIs is that they isolate the ho= st >> > implementation details from the device emulation. >> >> You're right "theoretically". =A0But what I've learned so far, >> there are cases like virtio-net and e1000 woks but virtio-blk >> doesn't. =A0"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. =A0If 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 requireme= nts > that weren't previously part of the API. =A0If the latter, then it's a bu= g like > any other. It's a problem if devices don't continue correctly upon failover. I would say it's a bug of live migration (not all of course) because Kemari is just live migrating at specific points. Yoshi > > Paul > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >