Pavel Dovgalyuk
> -----Original Message----- > From: Pavel Dovgalyuk [mailto:[email protected]] > Sent: Friday, January 19, 2018 3:37 PM > To: 'Paolo Bonzini'; 'Pavel Dovgalyuk'; [email protected] > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: RE: [RFC PATCH v4 13/23] cpus: only take BQL for sleeping threads > > > From: Paolo Bonzini [mailto:[email protected]] > > Sent: Friday, January 19, 2018 3:26 PM > > To: Pavel Dovgalyuk; 'Pavel Dovgalyuk'; [email protected] > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; > > [email protected]; [email protected] > > Subject: Re: [RFC PATCH v4 13/23] cpus: only take BQL for sleeping threads > > > > 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. Ah, I forgot about unlocking in tcg_cpu_exec. Now I see, that vcpu is taking the lock when trying to access the peripherals. Therefore, I have to fix all *_cpu_has_work, right? > 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. > > > 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? Pavel Dovgalyuk
