[Qemu-devel] Re: [PATCH v3 14/22] kvm: Fix race between timer signals and vcpu entry under !IOTHREAD

[Avi Kivity]

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<address@hidden>
> >>  CC: Stefan Hajnoczi<address@hidden>
> >>  ---
> >>
> >>  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