From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCVUA-0001Fu-0W for qemu-devel@nongnu.org; Tue, 07 Jul 2015 12:12:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCVU6-0002pu-0H for qemu-devel@nongnu.org; Tue, 07 Jul 2015 12:12:41 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:38581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCVU5-0002p5-R7 for qemu-devel@nongnu.org; Tue, 07 Jul 2015 12:12:37 -0400 Received: by wibdq8 with SMTP id dq8so188038461wib.1 for ; Tue, 07 Jul 2015 09:12:37 -0700 (PDT) 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> <558D7E11.80807@greensocs.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Tue, 07 Jul 2015 17:12:34 +0100 Message-ID: <87d2049cb1.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: Mark Burton Cc: mttcg@greensocs.com, Peter Maydell , Alexander Spyridakis , QEMU Developers , Paolo Bonzini , KONRAD =?utf-8?B?RnI=?= =?utf-8?B?w6lkw6lyaWM=?= Mark Burton writes: > Paolo, Alex, Alexander, > > Talking to Fred after the call about ways of avoiding the ‘stop the world’ (or rather ‘sync the world’) - we already discussed this on this thread. > One thing that would be very helpful would be some test cases around > this. We could then use Fred’s code to check some of the possible > solutions out…. Yeah we certainly could do with some. I'm currently investigating the memory barriers but TLB flushing might be easier to write at first. > > I’m not sure if there is wiggle room in Peter’s statement below. Can > the TLB operation be completed on one core, but not ‘seen’ by other > cores until they hit an exit…..? I suspect they can - assuming no other guest synchronisation primitive was in play who's to say the other cores weren't at their eventual PC already. However I suspect the key thing is the first core doesn't restart until all the other cores have caught up with their flush operations. > > Cheers > > Mark. > > >> On 26 Jun 2015, at 18:30, Frederic Konrad wrote: >> >> 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 >> Yes this is not the case as I implemented it. >> >> The rest of the TB will be executed before the tlb_flush work really happen. >> The old version did this, was slow and was a mess (if two VCPUs want to tlb_flush >> at the same time and an other tlb_flush_page.. it becomes tricky..) >> >> I think it's not really terrible if the other VCPU execute some stuff before doing the >> tlb_flush.? So the solution would be only to cut the TranslationBlock after instruction >> which require a tlb_flush? >> >> Thanks, >> Fred >> -- Alex Bennée