From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QF5aE-0002Wn-Ij for qemu-devel@nongnu.org; Wed, 27 Apr 2011 10:19:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QF5a8-0005Px-Jn for qemu-devel@nongnu.org; Wed, 27 Apr 2011 10:19:14 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:46096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QF5a8-0005Pg-Ev for qemu-devel@nongnu.org; Wed, 27 Apr 2011 10:19:08 -0400 Received: by pvg3 with SMTP id 3so1506334pvg.4 for ; Wed, 27 Apr 2011 07:19:06 -0700 (PDT) References: <201104261424.p3QEO5OV007271@mailsv02.y.ecl.ntt.co.jp> <4DB6DBE8.7050706@siemens.com> In-Reply-To: <4DB6DBE8.7050706@siemens.com> Mime-Version: 1.0 (iPod Mail 8G4) Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Message-Id: From: Yoshiaki Tamura Date: Wed, 27 Apr 2011 23:19:10 +0900 Subject: Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "kwolf@redhat.com" , =?iso-2022-jp?B?GyRCQmdCPBsoQiAbJEI3PRsoQg==?= , "dlaor@redhat.com" , "ananth@in.ibm.com" , "kvm@vger.kernel.org" , "mst@redhat.com" , "mtosatti@redhat.com" , "aliguori@us.ibm.com" , Yoshiaki Tamura , "qemu-devel@nongnu.org" , "blauwirbel@gmail.com" , "quintela@redhat.com" , "avi@redhat.com" , "vatsa@linux.vnet.ibm.com" , "pbonzini@redhat.com" , "psuriset@linux.vnet.ibm.com" , "stefanha@linux.vnet.ibm.com" On Apr 26, 2011, at 11:51 PM, Jan Kiszka wrote: > On 2011-04-26 16:24, "=1B$BBgB<=1B(B =1B$B7=3D=1B(B" wrote: >>=20 >> 2011/4/25 Jan Kiszka : >>> On 2011-04-25 13:00, OHMURA Kei wrote: >>>> From: Yoshiaki Tamura >>>>=20 >>>> Record mmio write event to replay it upon failover. >>>>=20 >>>> Signed-off-by: Yoshiaki Tamura >>>> Signed-off-by: OHMURA Kei >>>> --- >>>> exec.c | 4 ++++ >>>> 1 files changed, 4 insertions(+), 0 deletions(-) >>>>=20 >>>> 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 ad= dr, uint8_t *buf, >>>> io_index =3D (pd >> IO_MEM_SHIFT) & (IO_MEM_NB_ENTRIES -= 1); >>>> if (p) >>>> addr1 =3D (addr & ~TARGET_PAGE_MASK) + p->region_off= set; >>>> + >>>> + event_tap_mmio(addr, buf, len); >>>> + >>>=20 >>> You know that this is incomplete? A few devices are calling st*_phys >>> directly, specifically virtio. >>>=20 >>> What kind of mmio should be traced here, device or CPU originated? Or bo= th? >>>=20 >>> Jan >>>=20 >>>=20 >>=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 >=20 > OK, I see. >=20 > 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. Ho= wever, 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 >=20 > Jan >=20 > --=20 > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux