On Sat, Nov 27, 2010 at 1:11 PM, Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: > 2010/11/27 Stefan Hajnoczi <stefanha@xxxxxxxxx>: >> 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. > > Blue and Paul prefer to put it into block/net layer, and you > think it's better to provide API. Sorry, I wasn't clear. I agree that event tap behavior should be in generic block and net layer code. That way we're guaranteeing that all net and block I/O goes through event tap. >> 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 :). 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
