From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2182C47082 for ; Thu, 3 Jun 2021 17:52:18 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6FE5E613E3 for ; Thu, 3 Jun 2021 17:52:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FE5E613E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Xhf5u+rna4YuBWvZ85KkJrKf/0IMWbF/9/kgdCI3CTg=; b=mXiYsTEWZhLWWC J2EWdHNi/ekYIPyIknxkK3mdYNjKrgo0v2ff8gSHRQD9RyM0KV5l+aiEVgLaaLuZnMfWI8AUbVHM+ sANUcs6EDg6WjDswIT9xzIVmqHm0CDrjdxiqddd4i3FAvZ67X8RwGSiZtC6/poIQyq3nVKowVcokW 0J2qnhuQ7N+rLn1NnJbMy51b+eOzmylU16pVViPug6h5vmOB6t5LBVOTPq4SMv2kIsVpMUZMuxAmK PyayQ10hpyT9oMHEEW7drOpFRqBcaNUSZW0lArRieQc4/A4ri2IU7sjWTW896M9Yh6F+lEXZkmvud rkOt590fDphXb7nLR29g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lorUS-009yya-Ko; Thu, 03 Jun 2021 17:50:44 +0000 Received: from mail-il1-f181.google.com ([209.85.166.181]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lorUO-009ywP-7b for linux-arm-kernel@lists.infradead.org; Thu, 03 Jun 2021 17:50:42 +0000 Received: by mail-il1-f181.google.com with SMTP id x18so6371782ila.10 for ; Thu, 03 Jun 2021 10:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZOejtmCO69JibbX+7cczfFGvOyRor+CUYutED1lRdHY=; b=cMbiu0nxyM8o07bgVfB4BKA4y1KMAtLuab8bZ42OZ+b/iB2fBfbVPJ+4isbEt/DXs0 VI+7GguE2Wxr2zpuwBeLbUxvtjdpFO4t3DkSQvdKkzuAU3U5UK+bAoVHE2+ihcvDM7VC i4UH1jGXfl7xwnhAN+KT6Fa7WsjWZY91K8ADX9AmVl2SD7sKpnRdPk7IFiO0BNFXeZ7q uvcp6T4s9fSpBIYyQ56T9ubEhGk3lUaXMjlBk9Jdp/jznfPtuWRnAPfln9phTL5Yqwt0 UXq9LxsS+T0xPKOVebnmIu5PciOdzHeW/mheuqtus+2uf8xWJDLVGtb3m51VB/n3BmS2 Dn0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZOejtmCO69JibbX+7cczfFGvOyRor+CUYutED1lRdHY=; b=JUaFVW5QzCXhJJn0ZZoiy9KtHFLnB+AkIjkvfHa9NAtGyviUMSqDff+sxXxApUauNi wxPwgPNb2G7ml9kyjJqEnUk7ruSDVs32A0PFhief7paaQ7lxIejSwZ9ViYmsQWBWqVPn gqfM11SKeVlYdQCs/l6+vXDk2jg8rtWjOMweeAMDCZqygb71nfDIjgXvKPzLMLyS/Y5o THCkWD9L42A2CZKrKl42LYZJ7az/KMBJbZqGZceNp+LPfmWnISVOLPGseAZNKfpuVrur QgenXaiUmrNfDEZKi3RorlUUWPbI7swTELSLsG/CnWc5lee19f4zRjvQKOyXl7PEITEc erMQ== X-Gm-Message-State: AOAM530jMbuJB0zs2XpQeGkIlLLHG13JM+KirHp0wBwnoHgSSs5W+nwz 3K7+IFKerQOzztdUX3KqBbLE3tdZu7HVR4nSNJYtYg== X-Google-Smtp-Source: ABdhPJxlh9xwhD+XLMbRdycAcUYG+vrkOKX41LUNDgWQrY7U/IK/jypkHTI5oChJF5fF+qHsp8ojjWvKJO9s2s7SNn4= X-Received: by 2002:a92:ca83:: with SMTP id t3mr457172ilo.28.1622742575883; Thu, 03 Jun 2021 10:49:35 -0700 (PDT) MIME-Version: 1.0 References: <20210602232445.3829248-1-pcc@google.com> <5ee9d9a1-5b13-ea21-67df-e713c76fc163@arm.com> In-Reply-To: <5ee9d9a1-5b13-ea21-67df-e713c76fc163@arm.com> From: Peter Collingbourne Date: Thu, 3 Jun 2021 10:49:24 -0700 Message-ID: Subject: Re: [PATCH] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis To: Vincenzo Frascino Cc: Catalin Marinas , Will Deacon , Evgenii Stepanov , linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210603_105040_321474_6FC828EE X-CRM114-Status: GOOD ( 29.62 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jun 3, 2021 at 6:01 AM Vincenzo Frascino wrote: > > Hi Peter, > > On 6/3/21 12:24 AM, Peter Collingbourne wrote: > > On some CPUs the performance of MTE in synchronous mode is the same > > as that of asynchronous mode. This makes it worthwhile to enable > > synchronous mode on those CPUs when asynchronous mode is requested, > > in order to gain the error detection benefits of synchronous mode > > without the performance downsides. Therefore, make it possible for CPUs > > to opt into upgrading to synchronous mode via a new mte-prefer-sync > > device tree attribute. > > > > I had a look at your patch and I think that there are few points that are worth > mentioning: > 1) The approach you are using is per-CPU hence we might end up with a system > that has some PE configured as sync and some configured as async. We currently > support only a system wide setting. This is the intent. On e.g. a big/little system this means that we would effectively have sampling of sync MTE faults at a higher rate than a pure userspace implementation could achieve, at zero cost. > 2) async and sync have slightly different semantics (e.g. in sync mode the > access does not take place and it requires emulation) this means that a mixed > configuration affects the ABI. We considered the ABI question and think that is somewhat academic. While it's true that we would prevent the first access from succeeding (and, more visibly, use SEGV_MTESERR in the signal rather than SEGV_MTEAERR) I'm not aware of a reasonable way that a userspace program could depend on the access succeeding. While it's slightly more plausible that there could be a dependency on the signal type, we don't depend on that in Android, at least not in a way that would lead to worse outcomes if we get MTESERR instead of MTEAERR (it would lead to better outcomes, in the form of a more accurate/detailed crash report, which is what motivates this change). I also checked glibc and they don't appear to have any dependencies on the signal type, or indeed have any detailed crash reporting at all as far as I can tell. Furthermore, basically nobody has hardware at the moment so I don't think we would be breaking any actual users by doing this. > 3) In your patch you use DT to enforce sync mode on a CPU, probably it is better > to have an MIDR scheme to mark these CPUs. Okay, so in your scheme we would say that e.g. all Cortex-A510 CPUs should be subject to this treatment. Can we guarantee that all Cortex-A510 CPUs would have the same performance for sync and async or could the system designer tweak some aspect of the system such that they could get different performance? The possibility of the latter is what led me to specify the information via DT. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel