From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edVtO-0003Xs-MV for qemu-devel@nongnu.org; Mon, 22 Jan 2018 01:47:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edVtJ-0004ud-R7 for qemu-devel@nongnu.org; Mon, 22 Jan 2018 01:47:42 -0500 Received: from mail.ispras.ru ([83.149.199.45]:36106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edVtJ-0004tY-J4 for qemu-devel@nongnu.org; Mon, 22 Jan 2018 01:47:37 -0500 From: "Pavel Dovgalyuk" References: <20180119084235.7100.98318.stgit@pasha-VirtualBox> <20180119084417.7100.69568.stgit@pasha-VirtualBox> <002a01d3911d$dc13ca80$943b5f80$@ru> <8aa1900f-2663-43bd-dab5-001be0aede09@redhat.com> <002b01d39120$8c88e880$a59ab980$@ru> <002c01d39122$2de5d930$89b18b90$@ru> <29712321-7255-6714-ca80-b94d208c1a40@redhat.com> In-Reply-To: <29712321-7255-6714-ca80-b94d208c1a40@redhat.com> Date: Mon, 22 Jan 2018 09:47:33 +0300 Message-ID: <000c01d3934c$e19e6c90$a4db45b0$@ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Qemu-devel] [RFC PATCH v4 13/23] cpus: only take BQL for sleeping threads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Paolo Bonzini' , 'Pavel Dovgalyuk' , qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, boost.lists@gmail.com, quintela@redhat.com, jasowang@redhat.com, mst@redhat.com, zuban32s@gmail.com, maria.klimushenkova@ispras.ru, kraxel@redhat.com, alex.bennee@linaro.org > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > On 19/01/2018 13:36, Pavel Dovgalyuk wrote: > >> From: Paolo Bonzini [mailto:pbonzini@redhat.com] > >> 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