Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
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? 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
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
On Apr 26, 2011, at 11:51 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2011-04-26 16:24, 大村 圭 wrote: 2011/4/25 Jan Kiszka jan.kis...@web.de: On 2011-04-25 13:00, OHMURA Kei wrote: From: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Record mmio write event to replay it upon failover. Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp --- 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
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
On 2011-04-27 16:19, Yoshiaki Tamura wrote: 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? Additional entry points are ld/st*_phys helpers in exec.c and the magic that softmmu_template.h is generating. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
On Apr 27, 2011, at 2:51 PM, Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp 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
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
On 2011-04-26 16:24, 大村 圭 wrote: 2011/4/25 Jan Kiszka jan.kis...@web.de: On 2011-04-25 13:00, OHMURA Kei wrote: From: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Record mmio write event to replay it upon failover. Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp --- 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
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
2011/4/25 Jan Kiszka jan.kis...@web.de: On 2011-04-25 13:00, OHMURA Kei wrote: From: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Record mmio write event to replay it upon failover. Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp --- 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. Thanks, Kei
Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
On 2011-04-25 13:00, OHMURA Kei wrote: From: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Record mmio write event to replay it upon failover. Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp --- 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 signature.asc Description: OpenPGP digital signature
