qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v4 13/23] cpus: only take BQL for sleeping t


From: Pavel Dovgalyuk
Subject: Re: [Qemu-devel] [RFC PATCH v4 13/23] cpus: only take BQL for sleeping threads
Date: Fri, 19 Jan 2018 15:25:10 +0300


> -----Original Message-----
> From: Paolo Bonzini [mailto:address@hidden
> Sent: Friday, January 19, 2018 3:20 PM
> To: Pavel Dovgalyuk; 'Pavel Dovgalyuk'; address@hidden
> Cc: address@hidden; address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden; address@hidden; address@hidden;
> address@hidden; address@hidden
> 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:address@hidden
> >> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]