On 01/09/2017 04:18 PM, Max Filippov wrote: > 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?
Did you try "sleep" icount option? eg: -icount 1,sleep=off Fred > > - 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? >