Hi Namhyung, > On Aug 23, 2016, at 8:20 AM, Namhyung Kim <namhy...@kernel.org> wrote: > > Hi Joel, > > On Tue, Aug 23, 2016 at 7:25 PM, Joel Fernandes <agnel.j...@gmail.com> wrote: >> From: Namhyung Kim <namhy...@kernel.org> > >> >> Any thoughts on what you think about it? In your approach though, you >> wouldn't need a backing mem-path file which is the size of the guest >> RAM (which could be as big as the mem-path file). I wonder if the >> mem-path file can be created sparse, and/or Qemu has support to >> configure a certain part of guest RAM as file-backed memory and the >> rest of it from Anonymous memory (not backed by mem-path) so that >> the size of the mem-path file can be kept at a minimum. > > The pstore (ramoops) requires the region of the memory is preserved > across reboot. Is it possible when -mem-path is used? I think it’s
I believe the stock qemu won’t persist memory on its own without a reboot. I found atleast one post where someone was trying to make mem-path persist across a reboot and claimed to succeed: https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg03476.html > > Also my approach can handle streams of data bigger than the pstore > buffer size. Although we can extract the contents of mem-path file > periodically, it might be hard for externel process to know the right > time to extract and there's a possibility of information loss IMHO. > I agree, your approach is better for an emulated environment. Thanks, Joel > Thanks, > Namhyung
