10.01.2016 03:44, Peter Crosthwaite пишет:
On Sat, Jan 9, 2016 at 9:39 AM, Dmitry Osipenko <dig...@gmail.com> 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 <dig...@gmail.com>
---
  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