qemu-e2k/hw/core/ptimer.c

447 lines
13 KiB
C
Raw Normal View History

/*
* General purpose implementation of a simple periodic countdown timer.
*
* Copyright (c) 2007 CodeSourcery.
*
* This code is licensed under the GNU LGPL.
*/
#include "qemu/osdep.h"
#include "qemu/timer.h"
#include "hw/ptimer.h"
#include "migration/vmstate.h"
#include "qemu/host-utils.h"
#include "sysemu/replay.h"
#include "sysemu/qtest.h"
#include "block/aio.h"
#include "sysemu/cpus.h"
#define DELTA_ADJUST 1
#define DELTA_NO_ADJUST -1
struct ptimer_state
{
uint8_t enabled; /* 0 = disabled, 1 = periodic, 2 = oneshot. */
uint64_t limit;
uint64_t delta;
uint32_t period_frac;
int64_t period;
int64_t last_event;
int64_t next_event;
uint8_t policy_mask;
QEMUTimer *timer;
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
ptimer_cb callback;
void *callback_opaque;
/*
* These track whether we're in a transaction block, and if we
* need to do a timer reload when the block finishes. They don't
* need to be migrated because migration can never happen in the
* middle of a transaction block.
*/
bool in_transaction;
bool need_reload;
};
/* Use a bottom-half routine to avoid reentrancy issues. */
static void ptimer_trigger(ptimer_state *s)
{
s->callback(s->callback_opaque);
}
static void ptimer_reload(ptimer_state *s, int delta_adjust)
{
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
uint32_t period_frac;
uint64_t period;
uint64_t delta;
bool suppress_trigger = false;
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
/*
* Note that if delta_adjust is 0 then we must be here because of
* a count register write or timer start, not because of timer expiry.
* In that case the policy might require us to suppress the timer trigger
* that we would otherwise generate for a zero delta.
*/
if (delta_adjust == 0 &&
(s->policy_mask & PTIMER_POLICY_TRIGGER_ONLY_ON_DECREMENT)) {
suppress_trigger = true;
}
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
if (s->delta == 0 && !(s->policy_mask & PTIMER_POLICY_NO_IMMEDIATE_TRIGGER)
&& !suppress_trigger) {
ptimer_trigger(s);
}
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
/*
* Note that ptimer_trigger() might call the device callback function,
* which can then modify timer state, so we must not cache any fields
* from ptimer_state until after we have called it.
*/
delta = s->delta;
period = s->period;
period_frac = s->period_frac;
if (delta == 0 && !(s->policy_mask & PTIMER_POLICY_NO_IMMEDIATE_RELOAD)) {
delta = s->delta = s->limit;
}
if (s->period == 0) {
if (!qtest_enabled()) {
fprintf(stderr, "Timer with period zero, disabling\n");
}
timer_del(s->timer);
s->enabled = 0;
return;
}
if (s->policy_mask & PTIMER_POLICY_WRAP_AFTER_ONE_PERIOD) {
if (delta_adjust != DELTA_NO_ADJUST) {
delta += delta_adjust;
}
}
if (delta == 0 && (s->policy_mask & PTIMER_POLICY_CONTINUOUS_TRIGGER)) {
if (s->enabled == 1 && s->limit == 0) {
delta = 1;
}
}
if (delta == 0 && (s->policy_mask & PTIMER_POLICY_NO_IMMEDIATE_TRIGGER)) {
if (delta_adjust != DELTA_NO_ADJUST) {
delta = 1;
}
}
if (delta == 0 && (s->policy_mask & PTIMER_POLICY_NO_IMMEDIATE_RELOAD)) {
if (s->enabled == 1 && s->limit != 0) {
delta = 1;
}
}
if (delta == 0) {
if (!qtest_enabled()) {
fprintf(stderr, "Timer with delta zero, disabling\n");
}
timer_del(s->timer);
s->enabled = 0;
return;
}
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
/*
* Artificially limit timeout rate to something
* achievable under QEMU. Otherwise, QEMU spends all
* its time generating timer interrupts, and there
* is no forward progress.
* About ten microseconds is the fastest that really works
* on the current generation of host machines.
*/
if (s->enabled == 1 && (delta * period < 10000) && !use_icount) {
period = 10000 / delta;
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
period_frac = 0;
}
s->last_event = s->next_event;
s->next_event = s->last_event + delta * period;
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
if (period_frac) {
s->next_event += ((int64_t)period_frac * delta) >> 32;
}
timer_mod(s->timer, s->next_event);
}
static void ptimer_tick(void *opaque)
{
ptimer_state *s = (ptimer_state *)opaque;
bool trigger = true;
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
/*
* We perform all the tick actions within a begin/commit block
* because the callback function that ptimer_trigger() calls
* might make calls into the ptimer APIs that provoke another
* trigger, and we want that to cause the callback function
* to be called iteratively, not recursively.
*/
ptimer_transaction_begin(s);
if (s->enabled == 2) {
s->delta = 0;
s->enabled = 0;
} else {
int delta_adjust = DELTA_ADJUST;
if (s->delta == 0 || s->limit == 0) {
/* If a "continuous trigger" policy is not used and limit == 0,
we should error out. delta == 0 means that this tick is
caused by a "no immediate reload" policy, so it shouldn't
be adjusted. */
delta_adjust = DELTA_NO_ADJUST;
}
if (!(s->policy_mask & PTIMER_POLICY_NO_IMMEDIATE_TRIGGER)) {
/* Avoid re-trigger on deferred reload if "no immediate trigger"
policy isn't used. */
trigger = (delta_adjust == DELTA_ADJUST);
}
s->delta = s->limit;
ptimer_reload(s, delta_adjust);
}
if (trigger) {
ptimer_trigger(s);
}
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
ptimer_transaction_commit(s);
}
uint64_t ptimer_get_count(ptimer_state *s)
{
uint64_t counter;
if (s->enabled && s->delta != 0) {
int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
int64_t next = s->next_event;
int64_t last = s->last_event;
bool expired = (now - next >= 0);
bool oneshot = (s->enabled == 2);
/* Figure out the current counter value. */
if (expired) {
/* Prevent timer underflowing if it should already have
triggered. */
counter = 0;
} else {
uint64_t rem;
uint64_t div;
int clz1, clz2;
int shift;
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
uint32_t period_frac = s->period_frac;
uint64_t period = s->period;
if (!oneshot && (s->delta * period < 10000) && !use_icount) {
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
period = 10000 / s->delta;
period_frac = 0;
}
/* We need to divide time by period, where time is stored in
rem (64-bit integer) and period is stored in period/period_frac
(64.32 fixed point).
Doing full precision division is hard, so scale values and
do a 64-bit division. The result should be rounded down,
so that the rounding error never causes the timer to go
backwards.
*/
rem = next - now;
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
div = period;
clz1 = clz64(rem);
clz2 = clz64(div);
shift = clz1 < clz2 ? clz1 : clz2;
rem <<= shift;
div <<= shift;
if (shift >= 32) {
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
div |= ((uint64_t)period_frac << (shift - 32));
} else {
if (shift != 0)
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
div |= (period_frac >> (32 - shift));
/* Look at remaining bits of period_frac and round div up if
necessary. */
hw/ptimer: Fix issues caused by the adjusted timer limit value Multiple issues here related to the timer with a adjusted .limit value: 1) ptimer_get_count() returns incorrect counter value for the disabled timer after loading the counter with a small value, because adjusted limit value is used instead of the original. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 0, 1) 4) ptimer_get_count(t) <-- would return 10000 instead of 0 2) ptimer_get_count() might return incorrect value for the timer running with a adjusted limit value. For instance: 1) ptimer_stop(t) 2) ptimer_set_period(t, 1) 3) ptimer_set_limit(t, 10, 1) 4) ptimer_run(t) 5) ptimer_get_count(t) <-- might return value > 10 3) Neither ptimer_set_period() nor ptimer_set_freq() are adjusting the limit value, so it is still possible to make timer timeout value arbitrary small. For instance: 1) ptimer_set_period(t, 10000) 2) ptimer_set_limit(t, 1, 0) 3) ptimer_set_period(t, 1) <-- bypass limit correction Fix all of the above issues by adjusting timer period instead of the limit. Perform the adjustment for periodic timer only. Use the delta value instead of the limit to make decision whether adjustment is required, as limit could be altered while timer is running, resulting in incorrect value returned by ptimer_get_count. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Message-id: cd141f74f5737480ec586b9c7d18cce1d69884e2.1464367869.git.digetx@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-06-06 17:59:30 +02:00
if ((uint32_t)(period_frac << shift))
div += 1;
}
counter = rem / div;
if (s->policy_mask & PTIMER_POLICY_WRAP_AFTER_ONE_PERIOD) {
/* Before wrapping around, timer should stay with counter = 0
for a one period. */
if (!oneshot && s->delta == s->limit) {
if (now == last) {
/* Counter == delta here, check whether it was
adjusted and if it was, then right now it is
that "one period". */
if (counter == s->limit + DELTA_ADJUST) {
return 0;
}
} else if (counter == s->limit) {
/* Since the counter is rounded down and now != last,
the counter == limit means that delta was adjusted
by +1 and right now it is that adjusted period. */
return 0;
}
}
}
}
if (s->policy_mask & PTIMER_POLICY_NO_COUNTER_ROUND_DOWN) {
/* If now == last then delta == limit, i.e. the counter already
represents the correct value. It would be rounded down a 1ns
later. */
if (now != last) {
counter += 1;
}
}
} else {
counter = s->delta;
}
return counter;
}
void ptimer_set_count(ptimer_state *s, uint64_t count)
{
assert(s->in_transaction);
s->delta = count;
if (s->enabled) {
s->need_reload = true;
}
}
void ptimer_run(ptimer_state *s, int oneshot)
{
bool was_disabled = !s->enabled;
assert(s->in_transaction);
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
if (was_disabled && s->period == 0) {
if (!qtest_enabled()) {
fprintf(stderr, "Timer with period zero, disabling\n");
}
return;
}
s->enabled = oneshot ? 2 : 1;
if (was_disabled) {
s->need_reload = true;
}
}
/* Pause a timer. Note that this may cause it to "lose" time, even if it
is immediately restarted. */
void ptimer_stop(ptimer_state *s)
{
assert(s->in_transaction);
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
if (!s->enabled)
return;
s->delta = ptimer_get_count(s);
timer_del(s->timer);
s->enabled = 0;
s->need_reload = false;
}
/* Set counter increment interval in nanoseconds. */
void ptimer_set_period(ptimer_state *s, int64_t period)
{
assert(s->in_transaction);
s->delta = ptimer_get_count(s);
s->period = period;
s->period_frac = 0;
if (s->enabled) {
s->need_reload = true;
}
}
/* Set counter frequency in Hz. */
void ptimer_set_freq(ptimer_state *s, uint32_t freq)
{
assert(s->in_transaction);
s->delta = ptimer_get_count(s);
s->period = 1000000000ll / freq;
s->period_frac = (1000000000ll << 32) / freq;
if (s->enabled) {
s->need_reload = true;
}
}
/* Set the initial countdown value. If reload is nonzero then also set
count = limit. */
void ptimer_set_limit(ptimer_state *s, uint64_t limit, int reload)
{
assert(s->in_transaction);
s->limit = limit;
if (reload)
s->delta = limit;
if (s->enabled && reload) {
s->need_reload = true;
}
}
uint64_t ptimer_get_limit(ptimer_state *s)
{
return s->limit;
}
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
void ptimer_transaction_begin(ptimer_state *s)
{
assert(!s->in_transaction);
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
s->in_transaction = true;
s->need_reload = false;
}
void ptimer_transaction_commit(ptimer_state *s)
{
assert(s->in_transaction);
/*
* We must loop here because ptimer_reload() can call the callback
* function, which might then update ptimer state in a way that
* means we need to do another reload and possibly another callback.
* A disabled timer never needs reloading (and if we don't check
* this then we loop forever if ptimer_reload() disables the timer).
*/
while (s->need_reload && s->enabled) {
s->need_reload = false;
s->next_event = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
ptimer_reload(s, 0);
}
/* Now we've finished reload we can leave the transaction block. */
s->in_transaction = false;
}
const VMStateDescription vmstate_ptimer = {
.name = "ptimer",
.version_id = 1,
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT8(enabled, ptimer_state),
VMSTATE_UINT64(limit, ptimer_state),
VMSTATE_UINT64(delta, ptimer_state),
VMSTATE_UINT32(period_frac, ptimer_state),
VMSTATE_INT64(period, ptimer_state),
VMSTATE_INT64(last_event, ptimer_state),
VMSTATE_INT64(next_event, ptimer_state),
VMSTATE_TIMER_PTR(timer, ptimer_state),
VMSTATE_END_OF_LIST()
}
};
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
ptimer_state *ptimer_init(ptimer_cb callback, void *callback_opaque,
uint8_t policy_mask)
{
ptimer_state *s;
/* The callback function is mandatory. */
ptimer: Provide new transaction-based API Provide the new transaction-based API. If a ptimer is created using ptimer_init() rather than ptimer_init_with_bh(), then instead of providing a QEMUBH, it provides a pointer to the callback function directly, and has opted into the transaction API. All calls to functions which modify ptimer state: - ptimer_set_period() - ptimer_set_freq() - ptimer_set_limit() - ptimer_set_count() - ptimer_run() - ptimer_stop() must be between matched calls to ptimer_transaction_begin() and ptimer_transaction_commit(). When ptimer_transaction_commit() is called it will evaluate the state of the timer after all the changes in the transaction, and call the callback if necessary. In the old API the individual update functions generally would call ptimer_trigger() immediately, which would schedule the QEMUBH. In the new API the update functions will instead defer the "set s->next_event and call ptimer_reload()" work to ptimer_transaction_commit(). Because ptimer_trigger() can now immediately call into the device code which may then call other ptimer functions that update ptimer_state fields, we must be more careful in ptimer_reload() not to cache fields from ptimer_state across the ptimer_trigger() call. (This was harmless with the QEMUBH mechanism as the BH would not be invoked until much later.) We use assertions to check that: * the functions modifying ptimer state are not called outside a transaction block * ptimer_transaction_begin() and _commit() calls are paired * the transaction API is not used with a QEMUBH ptimer There is some slight repetition of code: * most of the set functions have similar looking "if s->bh call ptimer_reload, otherwise set s->need_reload" code * ptimer_init() and ptimer_init_with_bh() have similar code We deliberately don't try to avoid this repetition, because it will all be deleted when the QEMUBH version of the API is removed. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20191008171740.9679-3-peter.maydell@linaro.org
2019-10-08 19:17:21 +02:00
assert(callback);
s = g_new0(ptimer_state, 1);
s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, ptimer_tick, s);
s->policy_mask = policy_mask;
s->callback = callback;
s->callback_opaque = callback_opaque;
/*
* These two policies are incompatible -- trigger-on-decrement implies
* a timer trigger when the count becomes 0, but no-immediate-trigger
* implies a trigger when the count stops being 0.
*/
assert(!((policy_mask & PTIMER_POLICY_TRIGGER_ONLY_ON_DECREMENT) &&
(policy_mask & PTIMER_POLICY_NO_IMMEDIATE_TRIGGER)));
return s;
}
void ptimer_free(ptimer_state *s)
{
timer_free(s->timer);
g_free(s);
}