From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41579)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1Z8WW9-0007UO-Ny
	for qemu-devel@nongnu.org; Fri, 26 Jun 2015 12:30:18 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1Z8WW5-0001px-In
	for qemu-devel@nongnu.org; Fri, 26 Jun 2015 12:30:17 -0400
Received: from greensocs.com ([193.104.36.180]:35172)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1Z8WW5-0001pp-85
	for qemu-devel@nongnu.org; Fri, 26 Jun 2015 12:30:13 -0400
Message-ID: <558D7E11.80807@greensocs.com>
Date: Fri, 26 Jun 2015 18:30:09 +0200
From: Frederic Konrad <fred.konrad@greensocs.com>
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>
	<CAFEAcA9kK0Hpphyf18uVA7M9VQeFpKN-u5JrDw+uHoqCxs6UEA@mail.gmail.com>
In-Reply-To: <CAFEAcA9kK0Hpphyf18uVA7M9VQeFpKN-u5JrDw+uHoqCxs6UEA@mail.gmail.com>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>
Cc: mttcg@greensocs.com, Alexander Graf <agraf@suse.de>, Alexander Spyridakis <a.spyridakis@virtualopensystems.com>, Mark Burton <mark.burton@greensocs.com>, QEMU Developers <qemu-devel@nongnu.org>, Alistair Francis <alistair.francis@xilinx.com>, Guillaume Delbergue <guillaume.delbergue@greensocs.com>, =?UTF-8?B?QWxleCBCZW5uw6ll?= <alex.bennee@linaro.org>

On 26/06/2015 18:08, Peter Maydell wrote:
> On 26 June 2015 at 17:01, Paolo Bonzini <pbonzini@redhat.com> 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