From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WXdOQ-0000dK-Tz for qemu-devel@nongnu.org; Tue, 08 Apr 2014 17:17:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WXdOH-0003Zs-T3 for qemu-devel@nongnu.org; Tue, 08 Apr 2014 17:17:18 -0400 Message-ID: <53446751.1090005@gmail.com> Date: Tue, 08 Apr 2014 16:17:05 -0500 From: Tom Musta MIME-Version: 1.0 References: <1396817714-26768-1-git-send-email-agraf@suse.de> <5344545C.7060608@gmail.com> <534454CD.2060500@suse.de> In-Reply-To: <534454CD.2060500@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] PPC: Clean up DECR implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 4/8/2014 2:58 PM, Alexander Graf wrote: > On 04/08/2014 09:56 PM, Tom Musta wrote: >> On 4/6/2014 3:55 PM, Alexander Graf wrote: >> >> >>> @@ -806,6 +838,10 @@ clk_setup_cb cpu_ppc_tb_init (CPUPPCState *env, uint32_t freq) >>> tb_env = g_malloc0(sizeof(ppc_tb_t)); >>> env->tb_env = tb_env; >>> tb_env->flags = PPC_DECR_UNDERFLOW_TRIGGERED; >>> + if (env->insns_flags & PPC_SEGMENT_64B) { >>> + /* All Book3S 64bit CPUs implement level based DEC logic */ >>> + tb_env->flags |= PPC_DECR_UNDERFLOW_LEVEL; >>> + } >>> /* Create new timer */ >>> tb_env->decr_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &cpu_ppc_decr_cb, cpu); >>> if (0) { >> Equating Book3S with PPC_SEGMENT_64B is clever ... is it too clever? Especially since >> the SLB Bridge is in the phased-out category and consequently we should expect future >> Book3S implementations to not support this instruction category. > > Maybe it's too clever :). I'm very open to suggestions on how to figure this out otherwise. Or maybe we should just rework the way timers get created and make them be part of the core itself? > I don't think there are existing flags that successfully describe what you want. It seems to me that an overall timer configuration mechanism would be nice to have. This would include: - a list of timers supported by the processor (family) - read / write privileges for each timer. - additional attributes (e.g. edge triggered vs. level triggered DEC) It would be great to have good default configurations for the current Book III-S and Book III-E. Things like read/write perms have changed over time which makes this all that much more fun. I need a little time to study Book III-E and review some old documents (e.g. 601, 401/403, etc.). I'll propose something a little more concrete.