Messages in this thread | | | Subject | Re: [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3) | From | Joel <> | Date | Wed, 24 Aug 2016 00:10:22 -0700 |
| |
Hi Namhyung,
> On Aug 23, 2016, at 8:20 AM, Namhyung Kim <namhyung@kernel.org> wrote: > > Hi Joel, > > On Tue, Aug 23, 2016 at 7:25 PM, Joel Fernandes <agnel.joel@gmail.com> wrote: >> From: Namhyung Kim <namhyung@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
| |