Re: ptimer use of bottom-half handlers

[Peter Maydell]

On Fri, 27 Sep 2019 at 11:01, Peter Maydell <address@hidden> wrote:
> The ptimer API is basically a down-counter (with a lot of bells
> and whistles), with functions to do things like "read current count"
> and "write current count". When the counter hits zero it typically
> reloads, and the ptimer code notifies a callback function in the
> device that's using ptimer. In the current implementation this
> is done using a QEMU bottom-half handler, so ptimer_trigger()
> calls replay_bh_schedule_event() on a QEMUBH that it was passed
> by the device when it was initialized. The comment says this is
> "to avoid reentrancy issues". That's a bit vague, but I assume the
> idea is to avoid the code of the device's 'triggered' callback
> being called from within eg ptimer_set_count(), because the
> device might be in the middle of changing multiple parts of the
> ptimer's state, its own state might not be consistent, etc.

In the course of trying to do some conversions of devices to
the new API I've proposed, I figured out the other part of what
this "to avoid reentrancy issues" probably is referring to:
if the device's 'triggered' callback itself calls a ptimer
function like ptimer_run() then potentially it could recurse:
 ptimer_trigger() -> trigger callback -> ptimer_run() ->
  ptimer_reload() -> ptimer_trigger() -> ...

I need to think a bit more carefully about what is supposed
to happen here and what we want to have happen. I guess at
the moment we'll just schedule the QEMU BH to run again,
so the trigger callback is called again, but not recursively.
So we should probably cause that to happen in the new scheme
(conceptually, something like "the trigger callback is
implicitly considered to be called from within a tx begin/
commit block, so (a) it doesn't need to do begin/commit itself
and (b) if it does something resulting in a repeat trigger
the second call will happen after it returns, not recursively" ?)

thanks
-- PMM