All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: 'Paolo Bonzini' <pbonzini@redhat.com>,
	'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'Alex Bligh' <alex@alex.org.uk>,
	'Max Filippov' <jcmvbkbc@gmail.com>,
	'qemu-devel' <qemu-devel@nongnu.org>,
	'Pavel Dovgaluk' <Pavel.Dovgaluk@ispras.ru>,
	'Richard Henderson' <rth@twiddle.net>
Subject: Re: [Qemu-devel] implementing architectural timers using QEMU timers
Date: Tue, 17 Jan 2017 08:45:26 +0300	[thread overview]
Message-ID: <000c01d27084$e749e7a0$b5ddb6e0$@ru> (raw)
In-Reply-To: <f2f54dce-0e3f-2718-4b35-1321f5c2ae11@redhat.com>

> From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo Bonzini
> On 12/01/2017 13:19, Pavel Dovgalyuk wrote:
> >> 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.
> 
> My understanding (which may be wrong!) was that after gen_io_end you
> would exit with TB_EXIT_ICOUNT_EXPIRED and cpu->icount_decr.u16.high =
> -1, but indeed I don't see anything that calls cpu_interrupt in that
> path.
> 
> Maybe something like this:
> 
> diff --git a/include/exec/gen-icount.h b/include/exec/gen-icount.h
> index 050de59..c20d193 100644
> --- a/include/exec/gen-icount.h
> +++ b/include/exec/gen-icount.h
> @@ -73,6 +73,9 @@ static inline void gen_io_end(void)
>  {
>      TCGv_i32 tmp = tcg_const_i32(0);
>      tcg_gen_st_i32(tmp, cpu_env, -ENV_OFFSET + offsetof(CPUState, can_do_io));
> +    /* Make the next TB exit immediately with TB_EXIT_ICOUNT_EXPIRED.  */
> +    tcg_gen_st16_i32(-1, cpu_env,
> +                     -ENV_OFFSET + offsetof(CPUState, icount_decr.u16.high));
>      tcg_temp_free_i32(tmp);
>  }

I guess it will help, but this seems too general.
There are some IO cases that do not need breaking the execution.
E.g., rdtsc in x86 does not change any timers, but is translated as IO operation.
However, I think it doesn't called too often, therefore it will not affect on performance too much.

Pavel Dovgalyuk

  reply	other threads:[~2017-01-17  5:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09 15:18 [Qemu-devel] implementing architectural timers using QEMU timers Max Filippov
2017-01-09 15:41 ` Alex Bligh
2017-01-10 15:22   ` Max Filippov
2017-01-10  8:31 ` Pavel Dovgalyuk
2017-01-10 18:39   ` Max Filippov
2017-01-10 18:47     ` Peter Maydell
2017-01-10 18:51       ` Max Filippov
2017-01-12 11:28     ` Pavel Dovgalyuk
2017-01-12 12:01       ` Peter Maydell
2017-01-12 12:19         ` Pavel Dovgalyuk
2017-01-16 17:19           ` Paolo Bonzini
2017-01-17  5:45             ` Pavel Dovgalyuk [this message]
2017-01-17 18:20             ` Max Filippov
2017-01-15 21:52       ` Max Filippov
2017-01-10  9:10 ` Frederic Konrad
2017-01-10 18:45   ` Max Filippov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000c01d27084$e749e7a0$b5ddb6e0$@ru' \
    --to=dovgaluk@ispras.ru \
    --cc=Pavel.Dovgaluk@ispras.ru \
    --cc=alex@alex.org.uk \
    --cc=jcmvbkbc@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.