On 11/14/16 11:33, Daniel P. Berrange wrote: > On Mon, Nov 14, 2016 at 11:28:04AM +0100, Paolo Bonzini wrote: >> >> >> On 14/11/2016 11:10, Daniel P. Berrange wrote: >>> There's already patches posted to create a virtio-pstore device for >>> QEMU, which is what led me to suggest this as an option: >>> >>> https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg00381.html >> >> It's also possible to use UEFI as a pstore backend. > > Presumably that'll also require some QEMU patches to provide storage > for UEFI's pstore ?
Using UEFI non-volatile variables as a pstore backend is a guest kernel feature, and it already works transparently with OVMF utilizing QEMU's pflash device. If memory serves, the data to be written are broken into 1KB chunks, and saved as separate UEFI variables under a dedicated namespace GUID. https://bugzilla.redhat.com/show_bug.cgi?id=828497 (Private BZ -- I apologize to the non-RedHatter subscribers that read this.) (Also, not everyone has been enthusiastic about this feature: <https://bugzilla.redhat.com/show_bug.cgi?id=919485>.) Anyway, when I say "it works", I mean it works for the direct purpose of storing data (like saving dmesg at panic), and for retrieving data, from within the guest. (At a subsequent guest boot, possibly.) This is the scope of pstore in general, AIUI (see "Documentation/ABI/testing/pstore"). However, host-side insight into the OVMF/edk2 varstore format remains something we don't, and shouldn't, implement. In this regard, the UEFI variables that happen to contain pstore data are no different from other kinds of UEFI variables; they are equally opaque from the host side. (Unless we want to implement and maintain a large utility that reflects and tracks the multi-layer variable driver stack in edk2. "Unless" is rhetorical, we don't want that.) If host-side access is needed to the guest's phys-base / virt-base, then my first preference would be the guest agent (interrogated at guest startup), and my second preference would be virtio-pstore. I reckon virtio-pstore will take a new guest driver, and I suppose the host-side on-disk format is being designed for easy parsing. Thanks Laszlo
