[Qemu-devel] implementing architectural timers using QEMU timers

[Max Filippov]

Hello,

I'm trying to reimplement xtensa CCOUNT (cycle counter) and
CCOMPARE (CCOUNT-based timer interrupts) using QEMU
timers. That is CCOUNT value is derived from the
QEMU_CLOCK_VIRTUAL clock and CCOMPARE interrupts are
generated from the QEMU_CLOCK_VIRTUAL timer callbacks.
The code is here:
  https://github.com/OSLL/qemu-xtensa/commits/xtensa-ccount

I've got the following issues doing that:

- in non-icount mode I can often read CCOUNT and get a value
  that is greater than programmed CCOMPARE value, which
  means that QEMU timer must have been fired at that point, but
  no sign of timer callback being called. That is timer callback
  invocation lags behind due time.

  Is my understanding correct that there's no hard expectations
  that firing of QEMU timers will be correctly sequenced with
  readings of QEMU clock?

- I thought that could be improved in -icount mode, so I tried that.
  It is better with -icount, but it's still not 100% accurate. That is
  I was able to observe guest reading QEMU clock value that is
  past QEMU timer deadline before that timer callback was
  invoked.

  That sounds like a bug to me, is it?

- when guest sets a timer and halts itself waiting for timer
  interrupt with waiti opcode QEMU behaviour is very strange with
  -icount: regardless of the programmed timeout QEMU waits for
  about a second before it delivers interrupt, and, AFAICT,
  interrupt delivery it is not caused by the corresponding CCOUNT
  timer. I was able to track this issue down to the
  qemu_clock_use_for_deadline function, i.e. always returning true
  'fixes' that unwanted delay, but looking around the timer code
  I've got the impression that that's not the correct fix.

  Any suggestions on how to fix that?

-- 
Thanks.
-- Max