Re: [Qemu-devel] implementing architectural timers using QEMU timers

From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: 'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'Max Filippov' <jcmvbkbc@gmail.com>,
	'Pavel Dovgaluk' <Pavel.Dovgaluk@ispras.ru>,
	'qemu-devel' <qemu-devel@nongnu.org>,
	'Alex Bligh' <alex@alex.org.uk>,
	'Richard Henderson' <rth@twiddle.net>
Subject: Re: [Qemu-devel] implementing architectural timers using QEMU timers
Date: Thu, 12 Jan 2017 15:19:32 +0300	[thread overview]
Message-ID: <001301d26cce$21ad3d30$6507b790$@ru> (raw)
In-Reply-To: <CAFEAcA-AMJ33g9hO2k9oGJfDr-Fatk7TY+Sbs_wRC-OfCjWhmQ@mail.gmail.com>

> From: Peter Maydell [mailto:peter.maydell@linaro.org]
> On 12 January 2017 at 11:28, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:
> >> From: Max Filippov [mailto:jcmvbkbc@gmail.com]
> >> Ok, looks like what happens in my case is that instruction that
> >> sets CCOMPARE and thus changes remaining icount does not
> >> cause exit from the cpu_exec. So merely ending TB on
> >> QEMU_CLOCK_VIRTUAL timer update is not enough, I need to
> >> throw an exception of some kind? Or does the timer code need
> >> to take care of that?
> >
> > Yes, it seems that you should end the block with an exception,
> > to allow icount loop recalculate the timeouts.
> 
> Really? The ARM translate.c doesn't generate an exception.
> It just does
>  gen_io_end();
>  gen_lookup_tb();
> 
> (so we force a lookup of the next TB, but don't throw an
> exception of any kind).

Maybe I missing something. As far as I understand, changing the virtual timer 
notifies the iothread and os_host_main_loop_wait kicks the CPU thread.

But within that period of time before changing the timer and kicking the thread
CPU may proceed some instructions and the timer will be expired if it was set
to one of the soonest instructions.

Pavel Dovgalyuk