|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread |
Date: | Mon, 22 Aug 2011 16:00:09 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 |
On 08/22/2011 03:50 PM, Peter Maydell wrote:
> Enabling the I/O thread by default seems like an important part of declaring > 1.0. Besides allowing true SMP support with KVM, the I/O thread means that the > TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which > currently requires a (racey) signal based alarm system. Even with iothread it's still signal based (and still racy) -- the only way to get a thread currently executing TCG code to stop doing so is to send it a signal.
It's signal-based, but I'm not sure it's racy when single-threaded. This: /* ... tb_add_jump ... */ barrier(); if (likely(!env->exit_request)) { in cpu_exec, vs. this in the signal handler: void cpu_exit(CPUState *env) { env->exit_request = 1; cpu_unlink_tb(env); }together will make sure that only a single basic block is executed after an exit request.
The problems with user-level emulation arise from multiple threads concurrently execute the tb_add_jump or cpu_unlink_tb operations. My knowledge of user-level emulation is approximately zero, but I think it should be possible to make the race outcome predictable. That's because (1) cpu_unlink_tb is idempotent; (2) you don't really need to do anything in cpu_unlink_tb if the other thread is running tb_add_jump, because setting env->exit_request will avoid entering the CPU.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |