From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35500)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1ZdtV7-0006dT-7o
	for qemu-devel@nongnu.org; Mon, 21 Sep 2015 01:18:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1ZdtV3-00046z-UT
	for qemu-devel@nongnu.org; Mon, 21 Sep 2015 01:18:53 -0400
Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:38371)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1ZdtV3-00046t-Na
	for qemu-devel@nongnu.org; Mon, 21 Sep 2015 01:18:49 -0400
Received: by wiclk2 with SMTP id lk2so95109430wic.1
	for <qemu-devel@nongnu.org>; Sun, 20 Sep 2015 22:18:48 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
References: <1440375847-17603-1-git-send-email-cota@braap.org>
	<1440375847-17603-18-git-send-email-cota@braap.org>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <55FF9339.2060209@redhat.com>
Date: Mon, 21 Sep 2015 07:18:49 +0200
MIME-Version: 1.0
In-Reply-To: <1440375847-17603-18-git-send-email-cota@braap.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC 17/38] aie: add target helpers
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: "Emilio G. Cota" <cota@braap.org>, qemu-devel@nongnu.org, mttcg@listserver.greensocs.com
Cc: alex.bennee@linaro.org, Frederic Konrad <fred.konrad@greensocs.com>, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, guillaume.delbergue@greensocs.com



On 24/08/2015 02:23, Emilio G. Cota wrote:
> +void HELPER(aie_st_pre)(CPUArchState *env, target_ulong vaddr)
> +{
> +    if (unlikely(env->aie_lock_enabled)) {
> +        if (env->aie_locked) {
> +            return;
> +        }

Now that I've reviewed your code more carefully, the approach you're
using looks more promising than I thought.  There are advantages over
Alvise's code, namely:

- cache-line vs. page granularity

- avoiding the global TLB flush (due to the virtually indexed TLBs)

- easy support for user-mode emulation

and some of the disadvantages look more easily fixable than I thought,
too (e.g. TLB entry bloat).

The main advantage of Alvise's code, on the other hand, is the minimal
overhead when there are no active LL/SC combinations and the better
integration with TCG.

A random idea: would it be possible to move some of the helper code to
generated TCG code?  For example, maintaining a count of outstanding
load-locked operations and forcing the slow path for stores if it is
non-zero?

Paolo

> +        aie_st_lock_ret(env, vaddr, GETRA());
> +    } else {
> +        hwaddr paddr = h_get_st_phys(env, vaddr, GETRA());
> +
> +        if (unlikely(aie_entry_exists(paddr))) {
> +            h_aie_lock(env, paddr);
> +        }
> +    }
> +}