> -----Original Message----- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, January 19, 2018 3:20 PM > To: Pavel Dovgalyuk; 'Pavel Dovgalyuk'; qemu-devel@nongnu.org > Cc: kw...@redhat.com; peter.mayd...@linaro.org; boost.li...@gmail.com; > quint...@redhat.com; > jasow...@redhat.com; m...@redhat.com; zuban...@gmail.com; > maria.klimushenk...@ispras.ru; > kra...@redhat.com; alex.ben...@linaro.org > Subject: Re: [RFC PATCH v4 13/23] cpus: only take BQL for sleeping threads > > On 19/01/2018 13:05, Pavel Dovgalyuk wrote: > >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >> On 19/01/2018 09:44, Pavel Dovgalyuk wrote: > >>> while (all_cpu_threads_idle()) { > >>> + qemu_mutex_lock_iothread(); > >>> stop_tcg_kick_timer(); > >>> qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex); > >>> + qemu_mutex_unlock_iothread(); > >>> } > >> > >> cpu_has_work cannot be called outside BQL yet. You first need to access > >> cpu->interrupt_request with atomics. > >> > >> In general, testing the condition outside the mutex is a very dangerous > >> pattern (and I'm usually the one who enjoys dangerous patterns). > > > > It means, that I'll have to fix all the has_work function to avoid races, > > because x86_cpu_has_work may have them? > > Why only x86_cpu_has_work? > > Even reading cs->interrupt_request outside the mutex is unsafe.
All the vcpu function that access interrupt controller or peripheral state may be unsafe? How can it work safely then? Pavel Dovgalyuk
