All of lore.kernel.org
 help / color / mirror / Atom feed
From: "罗勇刚(Yonggang Luo)" <luoyonggang@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH 0/2] armv7m_systick: Rewrite to use ptimers
Date: Tue, 27 Oct 2020 04:54:21 +0800	[thread overview]
Message-ID: <CAE2XoE-dNO-guN8P6Btpzr_mB1C8kx4svoG=LioPYABF5HtBQQ@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8g-n4gqy0Az7cBsQJqcQpsc_vH2=VatqqdRt034YD5JQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3586 bytes --]

On Tue, Oct 27, 2020 at 4:44 AM Peter Maydell <peter.maydell@linaro.org>
wrote:
>
> Ping for review ?
>
Maybe nobody can review this, anyway, is that possible add a test case for
this?
I found https://github.com/oxidecomputer/qemu-systick-bug are simple enough.
> thanks
> -- PMM
>
> On Thu, 15 Oct 2020 at 16:18, Peter Maydell <peter.maydell@linaro.org>
wrote:
> >
> > This patch series rewrites our implementation of the armv7m systick
> > timer to use ptimers.
> >
> > The armv7m systick timer is a 24-bit decrementing, wrap-on-zero,
> > clear-on-write counter.  Our current implementation has various bugs
> > and dubious workarounds in it (for instance see
> > https://bugs.launchpad.net/qemu/+bug/1872237).
> >
> > We have an implementation of a simple decrementing counter and we put
> > a lot of effort into making sure it handles the interesting corner
> > cases (like "spend a cycle at 0 before reloading"), so rather than
> > trying to fix these all over again in systick's hand-rolled countdown
> > code it's much simpler to just rewrite it to use a ptimer.
> >
> > Unfortunately this is a migration compatibility break, which will
> > affect all M-profile boards.
> >
> > Among other bugs, this fixes
> > https://bugs.launchpad.net/qemu/+bug/1872237 : now writes to SYST_CVR
> > when the timer is enabled correctly do nothing; when the timer is
> > enabled via SYST_CSR.ENABLE, the ptimer code will (because of
> > POLICY_NO_IMMEDIATE_RELOAD) arrange that after one timer tick the
> > counter is reloaded from SYST_RVR and then counts down from there, as
> > the architecture requires.
> >
> > Side note: the trace from the test program in LP1872237 won't look
> > quite like it does on the hardware: under QEMU the "waiting for 1000
> > ms" debug printing generally reports a SYST_CVR value of 0.  This is
> > because QEMU's emulated CPU is comparatively fast and our systick has a
> > hard-wired value of 1MHz for the frequency of the 'external reference
> > clock', which means that execution of the guest code reaches "read
> > SYST_CVR" before the first tick of the timer clock after enabling of
> > the timer (which is where the reload of SYST_CVR from SYST_RVR is
> > required).  The exception is the first iteration, where the time QEMU
> > takes to translate the guest code is enough that the timer tick
> > happens before the register read.  You can also get the timer tick to
> > win the race by fiddling around with the -icount option (which
> > effectively is slowing down the emulated CPU speed).
> >
> > Some day we should model both the 'system_clock_scale' (ie the CPU
> > clock frequency) and the 'external reference clock' as QEMU clock
> > source/sinks so that board code can specify the correct reference
> > clock frequency.
> >
> > Patch 1 is a minor tweak to the ptimer code to suppress a spurious
> > warning message for the "timer callback function disabled the ptimer"
> > case, which the systick timer uses.  Patch 2 is the actual
> > conversion.
> >
> > thanks
> > -- PMM
> >
> >
> > Peter Maydell (2):
> >   hw/core/ptimer: Support ptimer being disabled by timer callback
> >   hw/timer/armv7m_systick: Rewrite to use ptimers
> >
> >  include/hw/timer/armv7m_systick.h |   3 +-
> >  hw/core/ptimer.c                  |   4 +
> >  hw/timer/armv7m_systick.c         | 124 +++++++++++++-----------------
> >  3 files changed, 58 insertions(+), 73 deletions(-)
> >
> > --
> > 2.20.1
> >
>


--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 4616 bytes --]

      reply	other threads:[~2020-10-26 20:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 15:18 [PATCH 0/2] armv7m_systick: Rewrite to use ptimers Peter Maydell
2020-10-15 15:18 ` [PATCH 1/2] hw/core/ptimer: Support ptimer being disabled by timer callback Peter Maydell
2020-10-26 21:45   ` Philippe Mathieu-Daudé
2020-10-15 15:18 ` [PATCH 2/2] hw/timer/armv7m_systick: Rewrite to use ptimers Peter Maydell
2020-10-15 15:31   ` Peter Maydell
2020-10-26 21:57     ` Philippe Mathieu-Daudé
2020-10-26 20:42 ` [PATCH 0/2] armv7m_systick: " Peter Maydell
2020-10-26 20:54   ` 罗勇刚(Yonggang Luo) [this message]

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='CAE2XoE-dNO-guN8P6Btpzr_mB1C8kx4svoG=LioPYABF5HtBQQ@mail.gmail.com' \
    --to=luoyonggang@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.