From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRhOI-0005D7-Fs for qemu-devel@nongnu.org; Fri, 05 Feb 2016 09:29:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRhOH-0003Ww-K5 for qemu-devel@nongnu.org; Fri, 05 Feb 2016 09:29:42 -0500 Received: from mail-vk0-x234.google.com ([2607:f8b0:400c:c05::234]:36505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRhOH-0003Wq-D1 for qemu-devel@nongnu.org; Fri, 05 Feb 2016 09:29:41 -0500 Received: by mail-vk0-x234.google.com with SMTP id c3so10864928vkb.3 for ; Fri, 05 Feb 2016 06:29:41 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <87io23nsqe.fsf@linaro.org> References: <1454506721-11843-1-git-send-email-peter.maydell@linaro.org> <1454506721-11843-6-git-send-email-peter.maydell@linaro.org> <87io23nsqe.fsf@linaro.org> From: Peter Maydell Date: Fri, 5 Feb 2016 14:29:21 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 5/7] target-arm: Add isread parameter to CPAccessFns List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= Cc: "Edgar E. Iglesias" , qemu-arm , QEMU Developers , Patch Tracking On 5 February 2016 at 14:20, Alex Benn=C3=A9e wrot= e: > > Peter Maydell writes: >> -typedef CPAccessResult CPAccessFn(CPUARMState *env, const ARMCPRegInfo = *opaque); >> +typedef CPAccessResult CPAccessFn(CPUARMState *env, >> + const ARMCPRegInfo *opaque, >> + bool isread); > > I guess my only comment here is we've extended the call for every access > check with another parameter (and associated TCG activity) for something > only one handler currently cares about. > > Is there an argument for an rwaccessfn() that we use for just those > registers that care about the detail? I know system registers are hardly > a fast path priority but I'm concerned about knock on effects on > performance. Have you done any measurements? I haven't measured, no, but since there are only 3 arguments the third argument is going to be in a register on any host architecture we care about, which means the overhead is just going to be a single "load constant 0 or 1 into register before the call". I think that's going to be lost in the noise compared to actually having to make the function call at all, the work the function call does, and then the second function call later to do the read or write. thanks -- PMM