Re: [Qemu-devel] [PATCH 00/21] Kemari for KVM 0.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux