Re: Memory image save/restore

From: Chris Lalancette
Date: Tue Apr 13 2004 - 13:31:15 EST


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@xxxxxxxxxxxx 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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/