On Fri, 27 Sep 2019 at 11:01, Peter Maydell <peter.mayd...@linaro.org> 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
