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

From: Max Filippov <jcmvbkbc@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Pavel Dovgalyuk <dovgaluk@ispras.ru>,
	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: Tue, 10 Jan 2017 10:51:04 -0800	[thread overview]
Message-ID: <CAMo8BfKTqxnR=ONdAfD1pWiGhsVOG5TiuS+0uRgAZWSCOuX3Ow@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA-6-_5S+0YzoJA9twdiPBYOsLPFwq5zT+uoxFpbmfVJKQ@mail.gmail.com>

On Tue, Jan 10, 2017 at 10:47 AM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 10 January 2017 at 18:39, Max Filippov <jcmvbkbc@gmail.com> wrote:
>> 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?
>
> Is your code calling gen_io_start() and gen_io_end() in the right
> places around where it generates code to do the CCOMPARE accesses ?
> (the rules for getting icount to work right are a bit fiddly)

Yes, it does. Without these calls qemu aborts if I actually try to
access timers. But these functions themselves don't guarantee
anything, as they just generate code that sets can_do_io in the
env to 1 and to 0.

-- 
Thanks.
-- Max