public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: YOSHIDA Masanori <masanori.yoshida.tv@hitachi.com>
To: Avi Kivity <avi@redhat.com>, Yanfei Zhang <zhangyanfei@cn.fujitsu.com>
Cc: mtosatti@redhat.com, ebiederm@xmission.com, luto@mit.edu,
	Joerg Roedel <joerg.roedel@amd.com>,
	dzickus@redhat.com, paul.gortmaker@windriver.com,
	ludwig.nussel@suse.de, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, kexec@lists.infradead.org,
	Greg KH <gregkh@linuxfoundation.org>,
	vgoyal@redhat.com, yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump
Date: Mon, 18 Jun 2012 16:25:12 +0900	[thread overview]
Message-ID: <4FDED7D8.7070106@hitachi.com> (raw)
In-Reply-To: <4FD9E3FF.4050906@redhat.com>

Hi, Avi, Yanfei

I'm YOSHIDA Masanori from Hitachi, a developer of livedump.

 >> And here is a new case from the LinuxCon Japan:
 >>
 >> Developers from Hitach are now developing a new livedump mechanism for the
 >> same reason as ours. They have come to the situation *many times* that guest
 >> machines crashed due to host's failures, in particular, under development.
 >
 > This has happened to me as well, possible even more times .  I don't
 > use crash dumps for debugging but different people may use different
 > techniques.

As Yanfei's introduction, I'm developing livedump for cases where
guests crash due to host's failures.

Especially in very important systems, it is strongly requested to
identify the root cause of any failure even if it is very rare.
For this purpose, crash dumps must be obtained.
Therefore, we think livedump technique must be applied to the
virtualization system on that kind of area.

 >>> After the buggy situation is reproduced, we panic the host *manually*.
 >>> Then we could use userland tools to get guest machine's crash dump from 
host machine's
 >>> with the feature provided by this patch set. Finally we could analyse them 
separately
 >>> to find which side causes the problem.
 >>>
 >>
 >> Could you please tell me your attitude towards this patch?
 >
 > I still dislike it conceptually.  But let me do a technical review of
 > the latest version.

Actually, current implementation of livedump is just a core part,
which dumps only the image of kernel space. And I'd like to expand
it to obtain guest image at the same time too.
Also for this situation, VMCSINFO seems necessary to be exported.

Thanks,
YOSHIDA Masanori

Yokohama Research Laboratory,
Hitachi, Ltd.

  reply	other threads:[~2012-06-18  7:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16  7:50 [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump zhangyanfei
2012-05-16  7:52 ` [PATCH v2 1/5] x86: Add helper variables and functions to hold VMCSINFO zhangyanfei
2012-06-14 13:28   ` Avi Kivity
2012-05-16  7:54 ` [PATCH v2 2/5] KVM: Export symbols for module vmcsinfo-intel zhangyanfei
2012-05-16  7:55 ` [PATCH v2 3/5] KVM-INTEL: Add new module vmcsinfo-intel to fill VMCSINFO zhangyanfei
2012-06-14 13:37   ` Avi Kivity
2012-06-15  3:03     ` HATAYAMA Daisuke
2012-05-16  7:56 ` [PATCH v2 4/5] ksysfs: Export VMCSINFO via sysfs zhangyanfei
2012-05-16  7:57 ` [PATCH v2 5/5] Documentation: Add ABI entry for sysfs file vmcsinfo and vmcsinfo_maxsize zhangyanfei
2012-06-14 13:21   ` Avi Kivity
2012-05-20 17:43 ` [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump Avi Kivity
2012-05-21  2:32   ` Yanfei Zhang
2012-05-21  8:34     ` Avi Kivity
2012-05-21  9:08       ` Yanfei Zhang
2012-05-21  9:36         ` Avi Kivity
2012-05-22  3:40           ` Yanfei Zhang
2012-05-28  5:25             ` Yanfei Zhang
2012-05-28 13:28               ` Avi Kivity
2012-05-29  7:06                 ` Yanfei Zhang
2012-06-11  5:35                   ` Yanfei Zhang
2012-06-14 13:15                     ` Avi Kivity
2012-06-18  7:25                       ` YOSHIDA Masanori [this message]
2012-05-21 18:58 ` Eric Northup
2012-05-22  3:53   ` Yanfei Zhang
2012-05-22 20:53     ` Eric Northup

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=4FDED7D8.7070106@hitachi.com \
    --to=masanori.yoshida.tv@hitachi.com \
    --cc=avi@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kexec@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludwig.nussel@suse.de \
    --cc=luto@mit.edu \
    --cc=mtosatti@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=vgoyal@redhat.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    --cc=zhangyanfei@cn.fujitsu.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