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: Mon, 22 Jan 2018 09:47:33 +0300

> From: Paolo Bonzini [mailto:address@hidden
> On 19/01/2018 13:36, Pavel Dovgalyuk wrote:
> >> From: Paolo Bonzini [mailto:address@hidden
> >> 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




reply via email to

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