Re: [Qemu-devel] [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

[Namhyung Kim <namhyung@kernel.org>]

Hi Joel,

On Tue, Aug 23, 2016 at 7:25 PM, Joel Fernandes <agnel.joel@gmail.com> wrote:
> From: Namhyung Kim <namhyung@kernel.org>
>
>> Hello,
>>
>> This is another iteration of the virtio-pstore work.  In this patchset
>> I addressed most of feedbacks from previous version and drooped the
>> support for PSTORE_TYPE_CONSOLE for simplicity.  It'll be added once the basic
>
> Hi Namhyung,
>
> This looks like a useful pstore backend. Great work.

Thanks!

>
> BTW, Have you considered using -mem-path in Qemu for this purpose?
> I was thinking about using this, and then somehow have kernel reserve
> a part of physical memory for the pstore. Then after the crash, or
> whenever you want to read the contents of the pstore on the host, you
> could just extract that part of the mem-path file.

I wasn't aware of the -mem-path option and it seems that the existing
ramoops pstore backend can take care of it.

>
> 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
better to use a separate region/file for pstore rather than being a part
of guest RAM or as you said, it'd be great if qemu supported such a
hybrid mem-path.

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.

Thanks,
Namhyung