> From: Paolo Bonzini [mailto:[email protected]] > On 19/01/2018 13:36, Pavel Dovgalyuk wrote: > >> From: Paolo Bonzini [mailto:[email protected]] > >> On 19/01/2018 13:25, Pavel Dovgalyuk wrote: > >>>>> 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? > >> > >> They do it inside the big QEMU lock. > > > > Right. Without these patches. > > They are within the replay lock. And BQL is not covering vcpu execution > > with these patches. > > Therefore RR will be ok and regular execution may encounter races? > > It means that I missed something in Alex ideas, because he prepared the > > initial patches. > > Yes. > > >> But here you're calling cpu_has_work (via all_cpu_threads_idle) outside > >> the lock. > > > > Yes, I see, but what we have to do? > > I don't know. But the idiom in these patches, > > while(...) { > lock() > cond_wait() > unlock() > } > > is unsafe as well, so the issue is more than just cpu_has_work.
Maybe it's better to omit this patch? It seems that replay and regular execution are ok without it. Pavel Dovgalyuk
