From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXZQO-0000g6-VF for qemu-devel@nongnu.org; Thu, 13 Dec 2018 17:25:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXZQK-0008Ic-Qx for qemu-devel@nongnu.org; Thu, 13 Dec 2018 17:25:44 -0500 Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]:36740) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gXZQJ-0007kx-US for qemu-devel@nongnu.org; Thu, 13 Dec 2018 17:25:40 -0500 Received: by mail-ot1-x343.google.com with SMTP id k98so3553579otk.3 for ; Thu, 13 Dec 2018 14:25:28 -0800 (PST) References: <20181213115503.24188-1-alex.bennee@linaro.org> <20181213115503.24188-2-alex.bennee@linaro.org> <87mup91nox.fsf@linaro.org> From: Richard Henderson Message-ID: Date: Thu, 13 Dec 2018 16:25:24 -0600 MIME-Version: 1.0 In-Reply-To: <87mup91nox.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v1 1/2] target/arm: kvm64 make guest debug AA32 break point aware List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= , Ard Biesheuvel Cc: Mark Rutland , Peter Maydell , qemu-arm , QEMU Developers , omair.javaid@linaro.org On 12/13/18 8:55 AM, Alex Bennée wrote: > > Ard Biesheuvel writes: > >> Hi Alex, >> >> Thanks again for looking into this. >> >> On Thu, 13 Dec 2018 at 12:55, Alex Bennée wrote: > >> >>> >>> int kvm_arch_insert_sw_breakpoint(CPUState *cs, struct kvm_sw_breakpoint *bp) >>> { >>> + CPUARMState *env = &ARM_CPU(cs)->env; >>> + int el = arm_current_el(env); >>> + bool is_aa64 = arm_el_is_aa64(env, el); >>> + const uint32_t *bpi = is_aa64 ? &brk_insn : &bkpt_insn; >>> + >>> if (have_guest_debug) { >>> if (cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)&bp->saved_insn, 4, 0) || >>> - cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)&brk_insn, 4, 1)) { >>> + cpu_memory_rw_debug(cs, bp->pc, (uint8_t *)bpi, 4, 1)) { >> >> Should we be dealing with endianness here? >> > > > I don't think so - everything eventually ends up (ld|st)n_p which deals > with the endianness details. I think Ard is right. You need to consider dynamic endianness with bswap_code(arm_sctlr_b(env)) r~ r~