[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_m
From: |
Yoshiaki Tamura |
Subject: |
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c. |
Date: |
Wed, 27 Apr 2011 23:19:41 +0900 |
On Apr 27, 2011, at 2:51 PM, Takuya Yoshikawa <address@hidden> wrote:
>
>>>> What kind of mmio should be traced here, device or CPU originated? Or both?
>>>>
>>>> Jan
>>>>
>>>>
>>>
>>> To let Kemari replay outputs upon failover, tracing CPU originated
>>> mmio (specifically write requests) should be enough.
>>> IIUC, we can reproduce device originated mmio as a result of cpu
>>> originated mmio.
>>>
>
> Sorry, but I don't understand why it is safe yet.
>
> The problem is not if the mmio's are to be replayed but if replaying
> them will produce the same result, is it?
No. That's the functionality of event-tap queuing.
The mmio tap is for recording which CPU originated mmio resulted in I/O
monitored at event-tap queuing.
We expect the replayed result to be same as the primary, but we don't have to
guarantee while it's queued.
Thanks,
Yoshi
>
> In other words, is it really idempotent?
>
> Takuya
>
>>
>> OK, I see.
>>
>> But this tap will only work for KVM. I think you either have to catch
>> the other paths that TCG could take as well or maybe better move the
>> hook into kvm-all - then it's absolutely clear that this is no generic
>> feature.
>>
>> Jan
>>