public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: YOSHIDA Masanori <masanori.yoshida.tv@hitachi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Vivek Goyal <vgoyal@redhat.com>,
	linux-kernel@vger.kernel.org, Andy Lutomirski <luto@mit.edu>,
	Ingo Molnar <mingo@elte.hu>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Kees Cook <keescook@chromium.org>, Kevin Hilman <khilman@ti.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Prarit Bhargava <prarit@redhat.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Tejun Heo <tj@kernel.org>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: [RFC PATCH 0/4 V2] introduce: livedump
Date: Mon, 04 Jun 2012 14:29:43 -0700	[thread overview]
Message-ID: <4FCD28C7.3050402@zytor.com> (raw)
In-Reply-To: <20120525091207.10256.18614.stgit@t3500.sdl.hitachi.co.jp>

On 05/25/2012 02:12 AM, YOSHIDA Masanori wrote:
> 
> Such a mechanism is useful especially in the case where very important
> systems are consolidated onto a single machine via virtualization.
> Assuming a KVM host runs multiple important VMs on it and one of them
> fails, the other VMs have to keep running. However, at the same time, an
> administrator may want to obtain memory dump of not only the failed guest
> but also the host because possibly the cause of failture is not in the
> guest but in the host or the hardware under it.
> 
> Live Dump is based on Copy-on-write technique. Basically processing is
> performed in the following order.
> (1) Suspends processing of all CPUs.
> (2) Makes pages (which you want to dump) read-only.
> (3) Resumes all CPUs
> (4) On page fault, dumps a page including a fault address.
> (5) Finally, dumps the rest of pages that are not updated.
> 
> Currently, Live Dump is just a simple prototype and it has many
> limitations. I list the important ones below.
> (1) It write-protects only kernel's straight mapping areas. Therefore
>     memory updates from vmap areas and user space don't cause page fault.
>     Pages corresponding to these areas are not consistently dumped.
> (2) It supports only x86-64 architecture.
> (3) It can only handle 4K pages. As we know, most pages in kernel space are
>     mapped via 2M or 1G large page mapping. Therefore, the current
>     implementation of Live Dump splits all large pages into 4K pages before
>     setting up write protection.
> (4) It allocates about 50% of physical RAM to store dumped pages. Currently
>     Live Dump saves all dumped data on memory once, and after that a user
>     becomes able to use the dumped data. Live Dump itself has no feature to
>     save dumped data onto a disk or any other storage device.
> 

I am very concerned about the impact of this patch versus its value...
losing half the RAM means the value is extremely limited and the other
limitations above indicates that the cost is very very high.

At the same time, the guest can be dumped without any special tricks.

	-hpa


      parent reply	other threads:[~2012-06-04 21:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25  9:12 [RFC PATCH 0/4 V2] introduce: livedump YOSHIDA Masanori
2012-05-25  9:12 ` [RFC PATCH 3/4 V2] livedump: Add write protection management YOSHIDA Masanori
2012-05-25  9:12 ` [RFC PATCH 2/4 V2] livedump: Add the new misc device "livedump" YOSHIDA Masanori
2012-05-25  9:12 ` [RFC PATCH 1/4 V2] livedump: Add notifier-call-chain into do_page_fault YOSHIDA Masanori
2012-05-25  9:19   ` Peter Zijlstra
2012-05-25 12:14     ` YOSHIDA Masanori
2012-05-25  9:12 ` [RFC PATCH 4/4 V2] livedump: Add memory dumping functionality YOSHIDA Masanori
2012-05-25  9:25 ` [RFC PATCH 0/4 V2] introduce: livedump Peter Zijlstra
2012-05-25 11:12   ` YOSHIDA Masanori
2012-06-04 21:09 ` Vivek Goyal
2012-06-05  9:50   ` YOSHIDA Masanori
2012-06-04 21:29 ` H. Peter Anvin [this message]

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=4FCD28C7.3050402@zytor.com \
    --to=hpa@zytor.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=keescook@chromium.org \
    --cc=khilman@ti.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=masanori.yoshida.tv@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=prarit@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --cc=yrl.pp-manager.tt@hitachi.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