From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3pUA-00006X-KF for qemu-devel@nongnu.org; Wed, 24 Dec 2014 12:12:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3pU7-0003WB-EA for qemu-devel@nongnu.org; Wed, 24 Dec 2014 12:12:34 -0500 Received: from mail-la0-f47.google.com ([209.85.215.47]:41149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3pU7-0003W1-7C for qemu-devel@nongnu.org; Wed, 24 Dec 2014 12:12:31 -0500 Received: by mail-la0-f47.google.com with SMTP id hz20so7335282lab.34 for ; Wed, 24 Dec 2014 09:12:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20141224165456.GA10393@dator> References: <1419377358-17222-1-git-send-email-rabin@rab.in> <20141224165456.GA10393@dator> From: Peter Maydell Date: Wed, 24 Dec 2014 17:12:09 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] target-arm: add dump-guest-memory support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rabin Vincent Cc: QEMU Developers On 24 December 2014 at 16:54, Rabin Vincent wrote: > On Tue, Dec 23, 2014 at 11:45:00PM +0000, Peter Maydell wrote: >> Assuming the answer is "still 64 bit core dump" you need >> to do something here to sync the 32 bit TCG state into the >> 64 bit xregs array. (KVM can take care of itself.) > > I have now tested this by triggering a dump while a 32-bit process is > incrementing a register in a tight loop, and the following, which I > lifted off the exception handling code, appears to work: > > if (!is_a64(&cpu->env)) { > int i; > > for (i = 0; i < 15; i++) { > prstatus.regs[i] = cpu->env.regs[i]; > } > } Yes, that looks OK, but can you factor it out to a function in target-arm/, please? When we add support for 32-bit EL1 in 64-bit EL2/EL3 it'll need to get more complicated. Also you need to use the read_cpsr() value for pstate. >> Note that in fact ARM is never going to be TARGET_WORDS_BIGENDIAN, >> even if the guest is big-endian, because the #define represents >> the bus endianness, not whether the CPU happens to currently be >> doing byte-swizzling. Do you need to key d_endian off the CPU's >> current endianness setting? The current endianness of EL1? >> Something else? > > IIUC we don't currently support anything other than little endian in > system emulation? Attempting to boot a BE ARMv7 vexpress kernel hits > the unimplementation of setend pretty quickly, and I don't see any > machine initializing the bswap_code to big endian. We don't currently in emulation; there are patches on-list to support it for KVM, though, which I expect we'll be merging shortly. (I really should resurrect that patchseries Paolo sent out to add BE support, it was pretty close but I think needed a few more tweaks.) > According the the ELF specification for ARM, the choice between > ELFDATA2LSB and ELFDATA2MSB "will be governed by the default data order > in the execution environment". Since we dump the full system memory I > would interpret this to be the "lowest" execution environment. So I > guess for ARM this would mean setting big endian if (SCTLR.EE || > SCTLR.B) and for AArch64 if SCTLR_EL1.E0E is set? I think AArch64 should be SCTLR_EL1.EE, shouldn't it? What are the semantics of the dump if we support EL2/EL3? Do we still just dump from the perspective of EL1? That's probably the best approximation to useful for a user I guess. -- PMM