2010/11/27 Blue Swirl <blauwirbel@xxxxxxxxx>: > On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura > <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: >> Hi, >> >> This patch series is a revised version of Kemari for KVM, which >> applied comments for the previous post and KVM Forum 2010. The >> 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 layer. >> - Introduce a new option for -incoming to accept FT transaction. >> - Removed writev() support to QEMUFile and FdMigrationState for now. I would >> post this work in a different series. >> - Modified virtio-blk save/load handler to send inuse variable to >> correctly 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. They introduce >> event-tap and the FT transaction protocol file based on buffered file. >> 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. Please 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. However it seems a bit tricky. It'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. In 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. I had the same idea but I'm not sure how tracing works. I think Stefan Hajnoczi knows it better. Stefan, is it possible to call arbitrary functions from the trace points? > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
