From: Stefan Hajnoczi <stefanha@gmail.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] pc: madvise(MADV_DONTNEED) memory on reset
Date: Sun, 28 Feb 2010 09:13:34 +0000 [thread overview]
Message-ID: <fbd9d3991002280113o609ed0d6r8ef823c8b103f48e@mail.gmail.com> (raw)
In-Reply-To: <1267038612-21581-1-git-send-email-aliguori@us.ibm.com>
On Wed, Feb 24, 2010 at 7:10 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> This patch addresses this issue by using madvise() during reset. It only
> resets RAM areas which means it has to be done in the machine. I've only done
> this for the x86 target because I'm fairly confident that this is allowed
> architecturally on x86 although I'm not sure this is universely true.
>
> This does not appear to have an observable cost with a large memory guest and
> I can't really think of any down sides.
Preserving the contents of memory across reboot seems to be common on
real x86 hardware. (Even if you hard power off and on again quickly.)
This behavior is useful for crash analysis. I use it as a tool for
debugging gPXE both on real hardware and under QEMU for example:
http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commitdiff;h=67344d8c3adca51658e1b8a80541a16e9f693a8d
posix_madvise() is fine but Linux MADV_DONTNEED will prevent this sort
of tool from working.
Would it be possible to make this configurable in some way? I can
imagine doing something like:
qemu> system_reset -preserve
Stefan
prev parent reply other threads:[~2010-02-28 9:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-24 19:10 [Qemu-devel] [PATCH] pc: madvise(MADV_DONTNEED) memory on reset Anthony Liguori
2010-02-24 20:59 ` Blue Swirl
2010-02-24 22:05 ` Anthony Liguori
2010-02-28 0:57 ` Paul Brook
2010-02-24 23:56 ` Samuel Thibault
2010-02-28 9:13 ` Stefan Hajnoczi [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=fbd9d3991002280113o609ed0d6r8ef823c8b103f48e@mail.gmail.com \
--to=stefanha@gmail.com \
--cc=aliguori@us.ibm.com \
--cc=qemu-devel@nongnu.org \
/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).