From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCrNc-0002YS-Vq for qemu-devel@nongnu.org; Wed, 08 Jul 2015 11:35:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCrNZ-0003uh-G9 for qemu-devel@nongnu.org; Wed, 08 Jul 2015 11:35:24 -0400 Received: from greensocs.com ([193.104.36.180]:37062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCrNZ-0003tY-3q for qemu-devel@nongnu.org; Wed, 08 Jul 2015 11:35:21 -0400 Message-ID: <559D4335.1000609@greensocs.com> Date: Wed, 08 Jul 2015 17:35:17 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <1435330053-18733-1-git-send-email-fred.konrad@greensocs.com> <1435330053-18733-16-git-send-email-fred.konrad@greensocs.com> <558D6C7E.6020905@redhat.com> <558D75D0.6060906@greensocs.com> <558D776E.20705@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH V6 15/18] cpu: introduce tlb_flush*_all. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Paolo Bonzini Cc: mttcg@greensocs.com, Alexander Graf , Alexander Spyridakis , Mark Burton , QEMU Developers , Alistair Francis , Guillaume Delbergue , =?UTF-8?B?QWxleCBCZW5uw6ll?= On 26/06/2015 18:08, Peter Maydell wrote: > On 26 June 2015 at 17:01, Paolo Bonzini wrote: >> On 26/06/2015 17:54, Frederic Konrad wrote: >>> So what happen is: >>> An arm instruction want to clear tlb of all VCPUs eg: IS version of >>> TLBIALL. >>> The VCPU which execute the TLBIALL_IS can't flush tlb of other VCPU. >>> It will just ask all VCPU thread to exit and to do tlb_flush hence the >>> async_work. >>> >>> Maybe the big issue might be memory barrier instruction here which I didn't >>> checked. >> Yeah, ISTR that in some cases you have to wait for other CPUs to >> invalidate the TLB before proceeding. Maybe it's only when you have a >> dmb instruction, but it's probably simpler for QEMU to always do it >> synchronously. > Yeah, the ARM architectural requirement here is that the TLB > operation is complete after a DSB instruction executes. (True for > any TLB op, not just the all-CPUs ones). NB that we also call > tlb_flush() from target-arm/ code for some things like "we just > updated a system register"; some of those have "must take effect > immediately" semantics. > > In any case, for generic code we have to also consider the > semantics of non-ARM guests... > > thanks > -- PMM Hi, About that we plan to: * make tlb_flush work sync and not async (in case of a tlb_flush_all). * break the TranslationBlock after a DSB. In this case when we have a tlb_flush_all, all VCPU's threads will exit and wait for all VCPUs to be out of cpu_exec before doing the flush. Then they won't be able to enter cpu_exec until any flush remains. So in case of a DSB, if there is any pending tlb_flush it won't be able to enter cpu_exec until it is done so we have the right behaviour I think. The obscur part is: what should happen if CPU A flush it's tlb itself and CPU B does a DSB? I'm not sure if this is really a problem if CPU A didn't finish it's TLB operation as the DSB might have happened before the flush operation? Do that makes sense? Thanks, Fred