qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v10 2/7] hw/ptimer: Perform tick and counter wrap


From: Dmitry Osipenko
Subject: Re: [Qemu-arm] [PATCH v10 2/7] hw/ptimer: Perform tick and counter wrap around if timer already expired
Date: Sun, 10 Jan 2016 17:09:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

10.01.2016 03:44, Peter Crosthwaite пишет:
On Sat, Jan 9, 2016 at 9:39 AM, Dmitry Osipenko <address@hidden> wrote:
ptimer_get_count() might be called while QEMU timer already been expired.
In that case ptimer would return counter = 0, which might be undesirable
in case of polled timer. Do counter wrap around for periodic timer to keep
it distributed. In order to achieve more accurate emulation behaviour of
certain hardware, don't perform wrap around when in icount mode and return
counter = 0 in that case (that doesn't affect polled counter distribution).

In addition, there is no reason to keep expired timer tick deferred, so
just perform the tick from ptimer_get_count().

Signed-off-by: Dmitry Osipenko <address@hidden>
---
  hw/core/ptimer.c | 26 +++++++++++++++++++-------
  1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/hw/core/ptimer.c b/hw/core/ptimer.c
index c3d31cb..cf329eb 100644
--- a/hw/core/ptimer.c
+++ b/hw/core/ptimer.c
@@ -83,14 +83,17 @@ static void ptimer_tick(void *opaque)

  uint64_t ptimer_get_count(ptimer_state *s)
  {
-    int64_t now;
+    int enabled = s->enabled;

You haven't added any additional usages of s->enabled to really
warrant the new local variable, I think it should just stay as
s->enabled to avoid churn.


Compiler doesn't know that ptimer struct is supposed to be thread-safe there and infers memory load instructions rather than use pure cpu registers. Local variable would help to produce somewhat more rational. However, given how optimized and complex modern cpu's, I'm not really sure that it would bring any benefit and agree that it might not worth churning. Thanks for review!

--
Dmitry



reply via email to

[Prev in Thread] Current Thread [Next in Thread]