From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9thY-0000IH-Mh for qemu-devel@nongnu.org; Fri, 18 Dec 2015 07:00:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9thX-0000MD-QM for qemu-devel@nongnu.org; Fri, 18 Dec 2015 07:00:00 -0500 Received: from mail-vk0-x235.google.com ([2607:f8b0:400c:c05::235]:33834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9thX-0000M4-E0 for qemu-devel@nongnu.org; Fri, 18 Dec 2015 06:59:59 -0500 Received: by mail-vk0-x235.google.com with SMTP id j66so63943584vkg.1 for ; Fri, 18 Dec 2015 03:59:58 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1450219878-5293-7-git-send-email-drjones@redhat.com> References: <1450219878-5293-1-git-send-email-drjones@redhat.com> <1450219878-5293-7-git-send-email-drjones@redhat.com> From: Peter Maydell Date: Fri, 18 Dec 2015 11:59:39 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v3 6/9] target-arm: support QMP dump-guest-memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Jones Cc: Markus Armbruster , Alexander Graf , QEMU Developers , qemu-arm , "qemu-ppc@nongnu.org" , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Richard Henderson On 15 December 2015 at 22:51, Andrew Jones wrote: > Add the support needed for creating prstatus elf notes. This > allows us to use QMP dump-guest-memory. > > Signed-off-by: Andrew Jones > +int arm_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cs, > + int cpuid, void *opaque) > +{ > + struct aarch64_note note; > + CPUARMState *env = &ARM_CPU(cs)->env; > + DumpState *s = opaque; > + uint64_t pstate, sp; > + int ret, i; > + > + aarch64_note_init(¬e, s, "CORE", 5, NT_PRSTATUS, sizeof(note.prstatus)); > + > + note.prstatus.pr_pid = cpu_to_dump32(s, cpuid); > + > + if (!is_a64(env)) { > + aarch64_sync_32_to_64(env); > + pstate = cpsr_read(env); > + sp = aarch64_compat_sp(env); I don't understand why we need to do this. If this is an AArch64 dump then we should just treat it as an AArch64 dump, and presumably the consumer of the dump knows enough to know what the "hypervisor view" of a CPU that's currently in 32-bit mode is. It has to anyway to be able to figure out where all the other registers are, so why can't it also figure out what mode the CPU is currently in and thus where r13 is in the xregs array? > + } else { > + pstate = pstate_read(env); > + sp = env->xregs[31]; > + } thanks -- PMM