From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46656 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMJmL-0002uM-3P for qemu-devel@nongnu.org; Sat, 27 Nov 2010 07:21:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMJmI-0007UJ-VA for qemu-devel@nongnu.org; Sat, 27 Nov 2010 07:21:21 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:54521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PMJmI-0007Tz-LC for qemu-devel@nongnu.org; Sat, 27 Nov 2010 07:21:18 -0500 Received: by wyg36 with SMTP id 36so2575959wyg.4 for ; Sat, 27 Nov 2010 04:21:17 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: References: <1290665220-26478-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> Date: Sat, 27 Nov 2010 21:21:17 +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: Blue Swirl Cc: ohmura.kei@lab.ntt.co.jp, mtosatti@redhat.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, Stefan Hajnoczi , dlaor@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com, vatsa@linux.vnet.ibm.com, psuriset@linux.vnet.ibm.com, ananth@in.ibm.com 2010/11/27 Blue Swirl : > On Sat, Nov 27, 2010 at 8:53 AM, Yoshiaki Tamura > wrote: >> 2010/11/27 Stefan Hajnoczi : >>> On Sat, Nov 27, 2010 at 4:29 AM, Yoshiaki Tamura >>> wrote: >>>> 2010/11/27 Blue Swirl : >>>>> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> This patch series is a revised version of Kemari for KVM, which >>>>>> applied comments for the previous post and KVM Forum 2010. =A0The >>>>>> current code is based on qemu.git >>>>>> f711df67d611e4762966a249742a5f7499e19f99. >>>>>> >>>>>> For general information about Kemari, I've made a wiki page at >>>>>> qemu.org. >>>>>> >>>>>> http://wiki.qemu.org/Features/FaultTolerance >>>>>> >>>>>> The changes from v0.1.1 -> v0.2 are: >>>>>> >>>>>> - Introduce a queue in event-tap to make VM sync live. >>>>>> - Change transaction receiver to a state machine for async receiving= . >>>>>> - Replace net/block layer functions with event-tap proxy functions. >>>>>> - Remove dirty bitmap optimization for now. >>>>>> - convert DPRINTF() in ft_trans_file to trace functions. >>>>>> - convert fprintf() in ft_trans_file to error_report(). >>>>>> - improved error handling in ft_trans_file. >>>>>> - add a tmp pointer to qemu_del_vm_change_state_handler. >>>>>> >>>>>> The changes from v0.1 -> v0.1.1 are: >>>>>> >>>>>> - events are tapped in net/block layer instead of device emulation l= ayer. >>>>>> - Introduce a new option for -incoming to accept FT transaction. >>>>>> - Removed writev() support to QEMUFile and FdMigrationState for now.= =A0I would >>>>>> =A0post this work in a different series. >>>>>> - Modified virtio-blk save/load handler to send inuse variable to >>>>>> =A0correctly replay. >>>>>> - Removed configure --enable-ft-mode. >>>>>> - Removed unnecessary check for qemu_realloc(). >>>>>> >>>>>> The first 6 patches modify several functions of qemu to prepare >>>>>> introducing Kemari specific components. >>>>>> >>>>>> The next 6 patches are the components of Kemari. =A0They introduce >>>>>> event-tap and the FT transaction protocol file based on buffered fil= e. >>>>>> The design document of FT transaction protocol can be found at, >>>>>> http://wiki.qemu.org/images/b/b1/Kemari_sender_receiver_0.5a.pdf >>>>>> >>>>>> Then the following 4 patches modifies dma-helpers, virtio-blk >>>>>> virtio-net and e1000 to replace net/block layer functions with >>>>>> event-tap proxy functions. =A0Please note that if Kemari is off, >>>>>> event-tap will just passthrough, and there is most no intrusion to >>>>>> exisiting functions including normal live migration. >>>>> >>>>> Would it be possible to make the changes only in the block/net layer, >>>>> so that the devices are not modified at all? That is, the proxy >>>>> function would always replaces the unproxied version. >>>> >>>> I understand the benefit of your suggestion. =A0However it seems a bit >>>> tricky. =A0It's because event-tap uses functions of emulators and net, >>>> but block.c is also linked for utilities like qemu-img that doesn't >>>> need emulators or net. =A0In the previous version, I added function >>>> pointers to get around. >>>> >>>> http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg02378.html >>>> >>>> I wasn't confident of this approach and discussed it at KVM Forum, and >>>> decided to give a try to replace emulator functions with proxies. >>>> Suggestions are welcomed of course. >>>> >>>>> Somehow I find some similarities to instrumentation patches. Perhaps >>>>> the instrumentation framework could be used (maybe with some changes) >>>>> for Kemari as well? That could be beneficial to both. >>>> >>>> Yes. =A0I had the same idea but I'm not sure how tracing works. =A0I t= hink >>>> Stefan Hajnoczi knows it better. >>>> >>>> Stefan, is it possible to call arbitrary functions from the trace >>>> points? >>> >>> Yes, if you add code to ./tracetool. =A0I'm not sure I see the >>> connection between Kemari and tracing though. >> >> The connection is that it may be possible to remove Kemari >> specific hook point like in ioport.c and exec.c, and let tracing >> notify Kemari instead. > > This all depends on how generic we want the trace points become. > > One possible extension to the event injection or instrumentation could > be fault injection: based on some rule, make the instrumented function > return error. That would be interesting for testing how guest handles > failure cases. > > Maybe it should be also possible to handle event injection in a > generic way. Split the instrumented function to two, before and after > the tracepoint. The tracepoint registers the tail function in addition > to the parameters. This may require a lot of refactoring though. The idea looks cool but it's a bit out of the range I can handle now:-) Let's keep the idea of binding with trace points for now, and focus on how to insert net/block tap points. >>> One question I have about Kemari is whether it adds new constraints to >>> the QEMU codebase? =A0Fault tolerance seems like a cross-cutting concer= n >>> - everyone writing device emulation or core QEMU code may need to be >>> aware of new constraints. =A0For example, "you are not allowed to >>> release I/O operations to the outside world directly, instead you need >>> to go through Kemari code which makes I/O transactional and >>> communicates with the passive host". =A0You have converted e1000, >>> virtio-net, and virtio-blk. =A0How do we make sure new devices that are >>> merged into qemu.git don't break Kemari? =A0How do we go about >>> supporting the existing hw/* devices? >> >> Whether Kemari adds constraints such as you mentioned, yes. =A0If >> the devices (including existing ones) don't call Kemari code, >> they would certainly break Kemari. =A0Altough using proxies looks >> explicit, to make it unaware from people writing device >> emulation, it's possible to remove proxies and put changes only >> into the block/net layer as Blue suggested. > > I'd prefer that approach if possible. Thanks. Let me see how others think too. Yoshi > -- > 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 >