qemu-devel
[Top][All Lists]
Advanced

[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:10 +0900

On Apr 26, 2011, at 11:51 PM, Jan Kiszka <address@hidden> wrote:

> On 2011-04-26 16:24, "大村 圭" wrote:
>> 
>> 2011/4/25 Jan Kiszka <address@hidden>:
>>> On 2011-04-25 13:00, OHMURA Kei wrote:
>>>> From: Yoshiaki Tamura <address@hidden>
>>>> 
>>>> Record mmio write event to replay it upon failover.
>>>> 
>>>> Signed-off-by: Yoshiaki Tamura <address@hidden>
>>>> Signed-off-by: OHMURA Kei <address@hidden>
>>>> ---
>>>> exec.c |    4 ++++
>>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>> 
>>>> diff --git a/exec.c b/exec.c
>>>> index c3dc68a..3c3cece 100644
>>>> --- a/exec.c
>>>> +++ b/exec.c
>>>> @@ -33,6 +33,7 @@
>>>> #include "osdep.h"
>>>> #include "kvm.h"
>>>> #include "qemu-timer.h"
>>>> +#include "event-tap.h"
>>>> #if defined(CONFIG_USER_ONLY)
>>>> #include <qemu.h>
>>>> #include <signal.h>
>>>> @@ -3736,6 +3737,9 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, 
>>>> uint8_t *buf,
>>>>                io_index = (pd >> IO_MEM_SHIFT) & (IO_MEM_NB_ENTRIES - 1);
>>>>                if (p)
>>>>                    addr1 = (addr & ~TARGET_PAGE_MASK) + p->region_offset;
>>>> +
>>>> +                event_tap_mmio(addr, buf, len);
>>>> +
>>> 
>>> You know that this is incomplete? A few devices are calling st*_phys
>>> directly, specifically virtio.
>>> 
>>> 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.
>> 
> 
> 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.

Hi Jan,

Indeed Kemari is for KVM, so moving to kvm-all.c seems to be reasonable.  
However, I would like to have this feature general rather than locking up only 
in KVM.

Could you describe the difference between KVM and TCG in processing mmio, so 
that we can see the issue?

Yoshi

> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux




reply via email to

[Prev in Thread] Current Thread [Next in Thread]