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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1471947901-3951-1-git-send-email-agnel.joel@gmail.com>
Date:   Tue, 23 Aug 2016 03:25:01 -0700
From:   Joel Fernandes <agnel.joel@...il.com>
To:     namhyung@...nel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCHSET 0/3] virtio: Implement virtio pstore device (v3)

From: Namhyung Kim <namhyung@...nel.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.

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.

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.

Thanks,
Joel