qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Tom Musta <tommusta@gmail.com>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] PPC: Clean up DECR implementation
Date: Tue, 08 Apr 2014 16:17:05 -0500	[thread overview]
Message-ID: <53446751.1090005@gmail.com> (raw)
In-Reply-To: <534454CD.2060500@suse.de>

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:
>> <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?
> 

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.

  reply	other threads:[~2014-04-08 21:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-06 20:55 [Qemu-devel] [PATCH v2] PPC: Clean up DECR implementation Alexander Graf
2014-04-08 19:56 ` Tom Musta
2014-04-08 19:58   ` Alexander Graf
2014-04-08 21:17     ` Tom Musta [this message]
2014-04-09 19:33     ` Tom Musta
2014-04-09 19:59       ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53446751.1090005@gmail.com \
    --to=tommusta@gmail.com \
    --cc=agraf@suse.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).