From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM1bx-0004y5-Qx for qemu-devel@nongnu.org; Mon, 16 May 2011 13:29:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QM1br-0001jU-G8 for qemu-devel@nongnu.org; Mon, 16 May 2011 13:29:41 -0400 Received: from hall.aurel32.net ([88.191.126.93]:46824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM1br-0001gr-8e for qemu-devel@nongnu.org; Mon, 16 May 2011 13:29:35 -0400 Date: Mon, 16 May 2011 19:29:23 +0200 From: Aurelien Jarno Message-ID: <20110516172923.GA6057@volta.aurel32.net> References: <1303401708-5419-1-git-send-email-peter.maydell@linaro.org> <20110425210953.GH21831@volta.aurel32.net> <20110425223146.GG6181@volta.aurel32.net> <20110426102307.GA20532@volta.aurel32.net> <20110514213247.GB13600@volta.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] target-arm: Minimal implementation of performance counters List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paul Brook , qemu-devel@nongnu.org, patches@linaro.org On Mon, May 16, 2011 at 10:59:47AM +0100, Peter Maydell wrote: > On 14 May 2011 22:32, Aurelien Jarno wrote: > > On Fri, May 06, 2011 at 03:32:27PM +0100, Peter Maydell wrote: > >> I just spoke with Paul on IRC about this. In summary: > >>  * for a helper to cause an exception then it has (a) to make sure CPU > >> state (pc, condflags) is sync'd before the call to the helper and (b) > >> the helper has to be in a file with access to global env, because it > >> needs to call cpu_loop_exit() > > > > I don't think (a) is true. It is possible to use the same way as for > > load/store operations, that is call cpu_restore_state() before calling > > cpu_loop_exit(). > > Yes, I think you're right here, I'm not sure why I didn't think that > would work. (b) still applies, though. > > > If you don't really like having env as a fixed host registers (recent > > patch series from Blue Swirl seems to want to get rid of this), it is > > possible to pass env as an argument of the helper to do that. > > I think really my position on this patch is that it adds > functionality that means you can't actually boot recent Linux > kernels with hw breakpoint support enabled, and I'd rather not > have it get tangled up with either the ongoing "remove AREG0" > discussions or a more general overhaul of how cp15 registers > are handled. It just handles this handful of new registers in > the same way we currently handle all the other cp14/cp15 regs. Well the current discussion is about to know if env access should be implicit (through a fixed register), or explicit (passed as an argument to the helper). Blue Swirl is working towards the second solution to see if it could work or not, so currently I think both options are still acceptable (both options are currently in use in the current code). > > What ever solution is used, we need env for the load/store functions, > > and theses functions already provide a framework to restore the CPU > > state. I think it's a good idea to use this framework instead of having > > a second framework using TCG code for that. > > Do you mean you'd like to see us using cpu_restore_state() instead > of explicit state-syncing TCG code for the cases where the exception > is "expected" like SVC instructions? (ie what most targets have > a gen_exception() function for.) > Well maybe this patch is not the best example to use cpu_restore_state(), but I think we should go toward this direction. Exceptions as their name suggests are not the rules, so we should avoid generating code to handle them (like state-syncing TCG code), and use CPU state restoration, even if it is not fast (that's not a problem, as exceptions are not the rules). That said given this patch is more or less an extension of an existing code, we may want to apply it anyway. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net