From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50262)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bk1wr-0000fZ-K7
	for qemu-devel@nongnu.org; Wed, 14 Sep 2016 00:37:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1bk1wl-0000zw-KZ
	for qemu-devel@nongnu.org; Wed, 14 Sep 2016 00:37:24 -0400
Message-ID: <1473827823.8689.329.camel@kernel.crashing.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 14 Sep 2016 14:37:03 +1000
In-Reply-To: <87twdj2l3y.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>
References: <1473659314-11813-1-git-send-email-nikunj@linux.vnet.ibm.com>
	<1473659314-11813-3-git-send-email-nikunj@linux.vnet.ibm.com>
	<20160914030941.GE15077@voom.fritz.box>
	<87twdj2l3y.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v3 2/3] target-ppc: add flag in
 chech_tlb_flush()
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: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>, David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org, alex.bennee@linaro.org, qemu-devel@nongnu.org, rth@twiddle.net

On Wed, 2016-09-14 at 09:23 +0530, Nikunj A Dadhania wrote:

Hr... this is confusing, let me rephrase ;-)

> Due to lazy tlb flushes, propagation of the tlb flush is delayed.
Moreover, certain operations need to do broadcast flush, this too can
be
> delayed until we hit the operation that warrant a broadcast.

Instead:

We flush the qemu TLB lazily. check_tlb_flush is called whenever we
hit a context synchronizing event or instruction that requires a pending
flush to be performed.

However, we fail to handle broadcast TLB flush operations. In order
to fix that efficiently, we want to differenciate whether check_tlb_flush()
needs to only apply pending local flushes (isync instructions,
interrupts, ...) or also global pending flush operations. The latter
is only needed when executing instructions that are defined architecturally
as synchronizing global TLB flush operations. This in our case is ptesync
on BookS and tlbsync on BookE along with the paravirtualized hypervisor
calls.

Cheers,
Ben.