From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46723) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1KpW-0007Ld-M5 for qemu-devel@nongnu.org; Tue, 24 Nov 2015 16:08:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1KpV-00062M-RY for qemu-devel@nongnu.org; Tue, 24 Nov 2015 16:08:50 -0500 Received: from mail-vk0-x231.google.com ([2607:f8b0:400c:c05::231]:35095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1KpV-00062D-MI for qemu-devel@nongnu.org; Tue, 24 Nov 2015 16:08:49 -0500 Received: by vkha189 with SMTP id a189so21137224vkh.2 for ; Tue, 24 Nov 2015 13:08:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20151124205231.GA4383@hawk.localdomain> References: <1447944817-13286-1-git-send-email-drjones@redhat.com> <1447944817-13286-6-git-send-email-drjones@redhat.com> <20151120214121.GC20402@hawk.localdomain> <20151121150537.GA3701@hawk.localdomain> <20151124205231.GA4383@hawk.localdomain> From: Peter Maydell Date: Tue, 24 Nov 2015 21:08:29 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 5/5] target-arm: support QMP dump-guest-memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: Alexander Graf , QEMU Developers , Markus Armbruster , qemu-arm@nongnu.org, "qemu-ppc@nongnu.org" , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Richard Henderson On 24 November 2015 at 20:52, Andrew Jones wrote: > > I've pulled a v2 together that I'll be testing and posting soon. Here's > what I decided to do > > 1) Throw the fp registers in. Why not? > 2) No linux-headers update, as we'd also need > include/uapi/linux/elfcore.h and arch/arm/include/asm/user.h. > However I've added comments stating where the structs come from. > 3) Base the vmcore type on the guest kernel, i.e. use arm_el_is_aa64() > and (env->cp15.sctlr_el[1] & SCTLR_EE). However, > aarch64_write_elf64_note() will shoehorn 32-bit state into 64-bit > elf notes when the current state is 32-bit. Those analyzing the > dumps will need to look at the captured pstate to determine the > endianness of the registers. Not sure what you have in mind by "endianness of the registers" -- typically registers aren't thought of as having endianness. Also, if we're currently executing a 32-bit guest when we take the core dump, you probably need to call aarch64_sync_32_to_64() somewhere. thanks -- PMM