From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34720)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WXc9v-0000qM-Hf
	for qemu-devel@nongnu.org; Tue, 08 Apr 2014 15:58:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WXc9n-0000DI-5f
	for qemu-devel@nongnu.org; Tue, 08 Apr 2014 15:58:15 -0400
Message-ID: <534454CD.2060500@suse.de>
Date: Tue, 08 Apr 2014 21:58:05 +0200
From: Alexander Graf <agraf@suse.de>
MIME-Version: 1.0
References: <1396817714-26768-1-git-send-email-agraf@suse.de>
	<5344545C.7060608@gmail.com>
In-Reply-To: <5344545C.7060608@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2] PPC: Clean up DECR implementation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Tom Musta <tommusta@gmail.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org

On 04/08/2014 09:56 PM, Tom Musta wrote:
> On 4/6/2014 3:55 PM, Alexander Graf wrote:
> <snip>
>
>> @@ -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?


Alex