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

[Stefan Hajnoczi]

On Sat, Nov 27, 2010 at 1:11 PM, Yoshiaki Tamura
<address@hidden> wrote:
> 2010/11/27 Stefan Hajnoczi <address@hidden>:
>> On Sat, Nov 27, 2010 at 8:53 AM, Yoshiaki Tamura
>> <address@hidden> wrote:
>>> 2010/11/27 Stefan Hajnoczi <address@hidden>:
>>>> On Sat, Nov 27, 2010 at 4:29 AM, Yoshiaki Tamura
>>>> <address@hidden> wrote:
>>>>> 2010/11/27 Blue Swirl <address@hidden>:
>>>>>> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
>>>>>> <address@hidden> 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