From: Jan Kiszka <jan.kiszka@siemens.com>
To: "大村 圭" <ohmura.kei@lab.ntt.co.jp>
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 <tamura.yoshiaki@lab.ntt.co.jp>,
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
Subject: Re: [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c.
Date: Tue, 26 Apr 2011 16:51:20 +0200 [thread overview]
Message-ID: <4DB6DBE8.7050706@siemens.com> (raw)
In-Reply-To: <201104261424.p3QEO5OV007271@mailsv02.y.ecl.ntt.co.jp>
On 2011-04-26 16:24, "大村 圭" wrote:
>
> 2011/4/25 Jan Kiszka <jan.kiszka@web.de>:
>> On 2011-04-25 13:00, OHMURA Kei wrote:
>>> From: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>>
>>> Record mmio write event to replay it upon failover.
>>>
>>> Signed-off-by: Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>
>>> Signed-off-by: OHMURA Kei <ohmura.kei@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
next prev parent reply other threads:[~2011-04-26 14:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-26 14:24 [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c "大村 圭"
2011-04-26 14:51 ` Jan Kiszka [this message]
2011-04-27 5:51 ` Takuya Yoshikawa
2011-04-27 14:19 ` Yoshiaki Tamura
2011-04-27 14:19 ` Yoshiaki Tamura
2011-04-27 15:00 ` Jan Kiszka
-- strict thread matches above, loose matches on Subject: below --
2011-04-25 11:00 [Qemu-devel] [PATCH 00/18] Kemari for KVM v0.2.14 OHMURA Kei
2011-04-25 11:00 ` [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c OHMURA Kei
2011-04-25 11:46 ` Jan Kiszka
2011-03-23 4:10 [Qemu-devel] [PATCH 00/18] [PATCH 00/18] Kemari for KVM v0.2.13 Yoshiaki Tamura
2011-03-23 4:10 ` [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c Yoshiaki Tamura
2011-02-24 7:28 [Qemu-devel] [PATCH 00/18] Kemari for KVM v0.2.12 Yoshiaki Tamura
2011-02-24 7:28 ` [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c Yoshiaki Tamura
2011-02-23 13:48 [Qemu-devel] [PATCH 00/18] Kemari for KVM v0.2.11 Yoshiaki Tamura
2011-02-23 13:48 ` [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c Yoshiaki Tamura
2011-02-10 9:30 [Qemu-devel] [PATCH 00/18] Kemari for KVM v0.2.10 Yoshiaki Tamura
2011-02-10 9:30 ` [Qemu-devel] [PATCH 12/18] Insert event_tap_mmio() to cpu_physical_memory_rw() in exec.c Yoshiaki Tamura
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DB6DBE8.7050706@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=aliguori@us.ibm.com \
--cc=ananth@in.ibm.com \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=dlaor@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=ohmura.kei@lab.ntt.co.jp \
--cc=pbonzini@redhat.com \
--cc=psuriset@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@linux.vnet.ibm.com \
--cc=tamura.yoshiaki@gmail.com \
--cc=tamura.yoshiaki@lab.ntt.co.jp \
--cc=vatsa@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).