From: Chris Lalancette <chris.lalancette@gd-ais.com>
To: pmarques@grupopie.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory image save/restore
Date: Tue, 13 Apr 2004 14:22:47 -0400 [thread overview]
Message-ID: <407C2FF7.4010500@gd-ais.com> (raw)
In-Reply-To: <407C1D4F.4060706@grupopie.com>
Paulo,
Thanks for responding. You are right in that the state of memory
isn't the state of the entire machine; however, for instance, the
swsusp2 project can save the contents of memory out to disk, go to
sleep, and then resume to it later. Basically, what I am trying to do
is something like swsusp2, with less restrictions; I know I have another
region the size of physical memory to work with, I know I am executing
from an interrupt handler, and at the end I don't want to go to sleep,
just continue on. Then I might want to use that memory image later.
Thanks,
Chris Lalancette
pmarques@grupopie.com wrote:
> Chris Lalancette wrote:
>
>> Hello all,
>>
>> I have been trying to implement some sort of save/restore kernel
>> memory image for the linux kernel (x86 only right now), without much
>> success. Let me explain the situation:
>>
>> I have a hardware device that I can generate interrupts with. I also
>> have a machine with 512M of memory, and I am passing the kernel the
>> command line mem=256M. My idea is to generate an interrupt with the
>> hardware device, and then inside of the interrupt handler make a copy
>> of the entire contents of RAM into the unused upper 256M of memory;
>> later on, with another interrupt, I would like to restore that
>> previously saved memory image. This way we can go "back in time",
>> similar to what software suspend is doing, but without as many
>> constraints (i.e. we have a hardware interrupt to work with, we
>> reserved the same amount of physical memory to use, etc.). Before I
>> went much further, I figured I would ask if anyone on the list has
>> tried this, and if there are any reasons why this is not possible.
>
>
> You're assuming that the state of the memory is the *state* of the
> entire system.
>
> This fails because there is a lot of state information in hardware
> registers, external peripheral devices, etc., etc.
>
next prev parent reply other threads:[~2004-04-13 18:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-13 16:44 Memory image save/restore Chris Lalancette
2004-04-13 17:03 ` Paulo Marques
2004-04-13 18:22 ` Chris Lalancette [this message]
2004-04-13 19:23 ` Paulo Marques
2004-04-13 19:48 ` Adam Kropelin
2004-04-15 14:11 ` Pavel Machek
2004-04-15 14:02 ` Pavel Machek
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=407C2FF7.4010500@gd-ais.com \
--to=chris.lalancette@gd-ais.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmarques@grupopie.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.