From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47585) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6F7y-00024X-9t for qemu-devel@nongnu.org; Mon, 14 Nov 2016 06:08:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6F7v-0006xk-1s for qemu-devel@nongnu.org; Mon, 14 Nov 2016 06:08:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54388) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6F7u-0006wt-Pw for qemu-devel@nongnu.org; Mon, 14 Nov 2016 06:08:38 -0500 References: <9144d6b1-a1c9-e727-4673-9df10b227fdb@redhat.com> <20161109113735.GF22181@redhat.com> <20161109114809.cawi6tpsxwn5vfql@kamzik.brq.redhat.com> <20161109115819.GG22181@redhat.com> <20161109122051.ztllxmhwsalds2qw@kamzik.brq.redhat.com> <20161109144740.GI22181@redhat.com> <20161114053256.GA16939@dhcp-128-65.nay.redhat.com> <20161114101030.GE8314@redhat.com> <20161114103342.GI8314@redhat.com> From: Laszlo Ersek Message-ID: Date: Mon, 14 Nov 2016 12:08:34 +0100 MIME-Version: 1.0 In-Reply-To: <20161114103342.GI8314@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , Paolo Bonzini Cc: Dave Young , Andrew Jones , bhe@redhat.com, qemu-devel@nongnu.org, qiaonuohan@cn.fujitsu.com, anderson@redhat.com 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: .) 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