From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecVue-0000V9-TF for qemu-devel@nongnu.org; Fri, 19 Jan 2018 07:36:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecVua-00046n-UO for qemu-devel@nongnu.org; Fri, 19 Jan 2018 07:36:52 -0500 Received: from mail.ispras.ru ([83.149.199.45]:52860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecVua-00043J-NH for qemu-devel@nongnu.org; Fri, 19 Jan 2018 07:36:48 -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> In-Reply-To: Date: Fri, 19 Jan 2018 15:36:50 +0300 Message-ID: <002c01d39122$2de5d930$89b18b90$@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] > Sent: Friday, January 19, 2018 3:26 PM > To: Pavel Dovgalyuk; '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 > 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. 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