From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c. Date: Tue, 26 Apr 2011 16:51:20 +0200 Message-ID: <4DB6DBE8.7050706@siemens.com> References: <201104261424.p3QEO5OV007271@mailsv02.y.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kwolf@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, ananth@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, Yoshiaki Tamura , vatsa@linux.vnet.ibm.com, blauwirbel@gmail.com, quintela@redhat.com, tamura.yoshiaki@gmail.com, avi@redhat.com, pbonzini@redhat.com, psuriset@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com To: =?UTF-8?B?5aSn5p2RIOWcrQ==?= Return-path: In-Reply-To: <201104261424.p3QEO5OV007271@mailsv02.y.ecl.ntt.co.jp> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 2011-04-26 16:24, "=E5=A4=A7=E6=9D=91 =E5=9C=AD" wrote: >=20 > 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 =3D (pd >> IO_MEM_SHIFT) & (IO_MEM_NB_ENTRI= ES - 1); >>> if (p) >>> addr1 =3D (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 >> >> >=20 > 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. >=20 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 --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux