On Sat, Nov 27, 2010 at 8:53 AM, Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: > 2010/11/27 Stefan Hajnoczi <stefanha@xxxxxxxxx>: >> On Sat, Nov 27, 2010 at 4:29 AM, Yoshiaki Tamura >> <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: >>> 2010/11/27 Blue Swirl <blauwirbel@xxxxxxxxx>: >>>> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura >>>> <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: >>>> 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? >> >> Yes, if you add code to ./tracetool. I'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. I actually think the other way. Tracing just instruments and stashes away values. It does not change inputs or outputs, it does not change control flow, it does not affect state. Going down the route of side-effects mixes two different things: hooking into a subsystem and instrumentation. For hooking into a subsystem we should define proper interfaces. That interface can explicitly support modifying inputs/outputs or changing control flow. Tracing is much more ad-hoc and not a clean interface. It's also based on a layer of indirection via the tracetool code generator. That's okay because it doesn't affect the code it is called from and you don't need to debug trace events (they are simple and have almost no behavior). Hooking via tracing is just taking advantage of the cheap layer of indirection in order to get at interesting events in a subsystem. It's easy to hook up and quick to develop, but it's not a proper interface and will be hard to understand for other developers. >> One question I have about Kemari is whether it adds new constraints to >> the QEMU codebase? Fault tolerance seems like a cross-cutting concern >> - everyone writing device emulation or core QEMU code may need to be >> aware of new constraints. For 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". You have converted e1000, >> virtio-net, and virtio-blk. How do we make sure new devices that are >> merged into qemu.git don't break Kemari? How do we go about >> supporting the existing hw/* devices? > > Whether Kemari adds constraints such as you mentioned, yes. If > the devices (including existing ones) don't call Kemari code, > they would certainly break Kemari. Altough 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. Anything that makes it hard to violate the constraints is good. Otherwise Kemari might get broken in the future and no one will know until a failover behaves incorrectly. 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? Stefan -- 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
