[Qemu-devel] Re: [PATCH 09/21] Introduce event-tap.

[Yoshiaki Tamura]

2010/11/30 Stefan Hajnoczi <address@hidden>:
> On Tue, Nov 30, 2010 at 9:50 AM, Yoshiaki Tamura
> <address@hidden> wrote:
>> 2010/11/29 Stefan Hajnoczi <address@hidden>:
>>> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
>>> <address@hidden> wrote:
>>>> event-tap controls when to start FT transaction, and provides proxy
>>>> functions to called from net/block devices.  While FT transaction, it
>>>> queues up net/block requests, and flush them when the transaction gets
>>>> completed.
>>>>
>>>> Signed-off-by: Yoshiaki Tamura <address@hidden>
>>>> Signed-off-by: OHMURA Kei <address@hidden>
>>>> ---
>>>>  Makefile.target |    1 +
>>>>  block.h         |    9 +
>>>>  event-tap.c     |  794 
>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  event-tap.h     |   34 +++
>>>>  net.h           |    4 +
>>>>  net/queue.c     |    1 +
>>>>  6 files changed, 843 insertions(+), 0 deletions(-)
>>>>  create mode 100644 event-tap.c
>>>>  create mode 100644 event-tap.h
>>>
>>> event_tap_state is checked at the beginning of several functions.  If
>>> there is an unexpected state the function silently returns.  Should
>>> these checks really be assert() so there is an abort and backtrace if
>>> the program ever reaches this state?
>
> Fancier error handling would work too.  For example cleaning up,
> turning off Kemari, and producing an error message with
> error_report().  In that case we need to think through the state of
> the environment carefully and make sure we don't cause secondary
> failures (like memory leaks).

Turning off Kemari should include canceling the transaction which
notifies the secondary.  So same as you commented for
ft_trans_file error handling, I would implement better handling
for event-tap again.

>> BTW, I would like to ask a question regarding this.  There is a
>> callback which net/block calls after processing the requests, and
>> is there a clean way to set this callback on the failovered
>> host upon replay?
>
> I think this is a limitation in the current design.  If requests are
> re-issued by Kemari at the net/block level, how will the higher layers
> know about these requests?  How will they be prepared to accept
> callbacks?

That's why we're using pio/mmio replay at this moment.  With a
dirty hack in device emulators setting callbacks before replay,
block/net replay seems to work, but I don't think that to be a
correct solution.

Yoshi

>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>