On 01/31/2011 01:27 PM, Jan Kiszka wrote:
On 2011-01-31 11:03, Avi Kivity wrote:
> On 01/27/2011 04:33 PM, Jan Kiszka wrote:
>> Found by Stefan Hajnoczi: There is a race in kvm_cpu_exec between
>> checking for exit_request on vcpu entry and timer signals arriving
>> before KVM starts to catch them. Plug it by blocking both timer related
>> signals also on !CONFIG_IOTHREAD and process those via signalfd.
>>
>> As this fix depends on real signalfd support (otherwise the timer
>> signals only kick the compat helper thread, and the main thread hangs),
>> we need to detect the invalid constellation and abort configure.
>>
>> Signed-off-by: Jan Kiszka<jan.kis...@siemens.com>
>> CC: Stefan Hajnoczi<stefa...@linux.vnet.ibm.com>
>> ---
>>
>> I don't want to invest that much into !IOTHREAD anymore, so let's see if
>> the proposed catch&abort is acceptable.
>>
>
> I don't understand the dependency on signalfd. The normal way of doing
> things, either waiting for the signal in sigtimedwait() or in
> ioctl(KVM_RUN), works with SIGALRM just fine.
And how would you be kicked out of the select() call if it is waiting
with a timeout? We only have a single thread here.
If we use signalfd() (either kernel provided or thread+pipe), we kick
out of select by select()ing it (though I don't see how it works without
an iothread, since an fd can't stop a vcpu unless you enable SIGIO on
it, which is silly for signalfd)
If you leave it as a naked signal, then it can break out of either
pselect() or vcpu.
Since the goal is to drop !CONFIG_IOTHREAD, the first path seems better,
I just don't understand the problem with emulated signalfd().
--
error compiling committee.c: too many arguments to function
