Re: [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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 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 >> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 wrote: > On 2011-04-26 16:24, "大村 圭" wrote: >> >> 2011/4/25 Jan Kiszka : >>> On 2011-04-25 13:00, OHMURA Kei wrote: From: Yoshiaki Tamura Record mmio write event to replay it upon failover. Signed-off-by: Yoshiaki Tamura Signed-off-by: OHMURA Kei --- 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 #include @@ -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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 : >> On 2011-04-25 13:00, OHMURA Kei wrote: >>> From: Yoshiaki Tamura >>> >>> Record mmio write event to replay it upon failover. >>> >>> Signed-off-by: Yoshiaki Tamura >>> Signed-off-by: OHMURA Kei >>> --- >>> 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 >>> #include >>> @@ -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [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 > > Record mmio write event to replay it upon failover. > > Signed-off-by: Yoshiaki Tamura > Signed-off-by: OHMURA Kei > --- > 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 > #include > @@ -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