On 2011-04-26 16:24, "åæ å" wrote: > > 2011/4/25 Jan Kiszka <jan.kiszka@xxxxxx>: >> On 2011-04-25 13:00, OHMURA Kei wrote: >>> From: Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> >>> >>> Record mmio write event to replay it upon failover. >>> >>> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> >>> Signed-off-by: OHMURA Kei <ohmura.kei@xxxxxxxxxxxxx> >>> --- >>> 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
