On 06/27/2016 02:20 PM, Sergey Fedorov wrote:
On 03/06/16 23:40, Alex Bennée wrote:diff --git a/cpus.c b/cpus.c index 1694ce9..12e04c9 100644 --- a/cpus.c +++ b/cpus.c @@ -1208,9 +1208,29 @@ static int tcg_cpu_exec(CPUState *cpu) return ret; }+/* Single-threaded TCG + * + * In the single-threaded case each vCPU is simulated in turn. If + * there is more than a single vCPU we create a simple timer to kick + * the vCPU and ensure we don't get stuck in a tight loop in one vCPU. + * This is done explicitly rather than relying on side-effects + * elsewhere. + */ +static void qemu_cpu_kick_no_halt(void); +#define TCG_KICK_FREQ (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + \ + NANOSECONDS_PER_SECOND / 10)Hmm, it doesn't look nice to wrap calculation of the next timeout in a macro and name it '*_FREQ'. I think we'd better do like this: #define TCG_KICK_PERIOD (NANOSECONDS_PER_SECOND / 10) static inline int64_t qemu_tcg_next_kick(void) { return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + TCG_KICK_PERIOD; } and use it like this: timer_mod(kick_timer, qemu_tcg_next_kick());
Agreed. As an aside, surely a period of 10ns is too small. That's on the order of 20-50 host instructions. r~
