From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQbiN-0003h8-Fh for qemu-devel@nongnu.org; Mon, 09 Jan 2017 10:18:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cQbiM-0001Uw-EM for qemu-devel@nongnu.org; Mon, 09 Jan 2017 10:18:27 -0500 Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]:37737) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cQbiM-0001Uo-AX for qemu-devel@nongnu.org; Mon, 09 Jan 2017 10:18:26 -0500 Received: by mail-it0-x22d.google.com with SMTP id r185so25161144ita.0 for ; Mon, 09 Jan 2017 07:18:24 -0800 (PST) MIME-Version: 1.0 From: Max Filippov Date: Mon, 9 Jan 2017 07:18:23 -0800 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] implementing architectural timers using QEMU timers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Cc: Richard Henderson , Alex Bligh , Pavel Dovgaluk 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