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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 86733C433E9 for ; Thu, 4 Mar 2021 08:20:47 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 17B1064EE8 for ; Thu, 4 Mar 2021 08:20:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 17B1064EE8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marcan.st 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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TWrW1ZSKUVsh7NR32O/uD9UmMgm7+JDU3zMv4kLHP3U=; b=VDymN6Dqzqk7FWoj+JsTx0qxc mLpChAL/t5z0RdzI652h0r5fXWE0xaiKaQDgtEy90BSgu/FW7d6OiWSmt5qcVU8d3RRNQVhnMSe80 qv7+kgXOVk0+Bm6mZD6xOrvWUKVCKvatiIps4Tq1ED7MCCSC8uSxcvT9H5nSORLgmBGRL0K4/sARg FvtXY+iCEF63zR1DavNMtp+c0gUnbJpA0JfphUV0BzPza57LchMRW4iCsIfiVQbswV5ZTsJkbZK5/ 0lipbYcDgd1Keu6R6n5lIPYFMcVLvPJRpG374cl1jNvHj6QouQisW5gv1XWSpozYs7FWMOcd/4h1j GnAfvNEJQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHjCP-0087iD-BI; Thu, 04 Mar 2021 08:19:09 +0000 Received: from marcansoft.com ([212.63.210.85] helo=mail.marcansoft.com) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHj9u-0087UE-94 for linux-arm-kernel@lists.infradead.org; Thu, 04 Mar 2021 08:16:43 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id F12EC3FA1B; Thu, 4 Mar 2021 08:16:30 +0000 (UTC) To: Will Deacon Cc: Linux ARM , Marc Zyngier , Mark Rutland , Peter Zijlstra , Boqun Feng , Catalin Marinas References: <90ea3e27-b2ef-41ac-75c7-5f0686603b2a@marcan.st> <20210303153619.GA19247@willie-the-truck> <20210303184055.GA19891@willie-the-truck> <0d194019-deb9-8d9b-823c-4226f2d2dce2@marcan.st> <20210303213815.GC20055@willie-the-truck> From: Hector Martin Subject: Re: LSE atomic op ordering is weaker than intended? Message-ID: <3bec5494-e5fe-455a-7411-bdc635517a17@marcan.st> Date: Thu, 4 Mar 2021 17:16:29 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210303213815.GC20055@willie-the-truck> Content-Language: es-ES 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 04/03/2021 06.38, Will Deacon wrote: > One thing to bear in mind here is that the MMIO device cannot "observe" > anything in the architectural sense because it is a slave interface. In > order to observe a memory access, you must emit a read or a write > transaction, and it's this notion of observation which the shareability > domains are built around. > > So for this example, we can talk about the CPUs (in the inner-shareable > domain) observing the MMIO writes and inner-shareable barriers are > sufficient for that. The device mapping of the MMIO registers will then > ensure that they arrive at the endpoint in that order too. Ah! That makes sense now. So as long as the CPUs agree about the MMIO ordering, the endpoint will see that ordering too. In that case I should be able to get away with simple SMP/atomic barriers (or nothing where the control dependency implies order). > Hopefully, as I don't grok how this deals with spurious interrupts if it > only does MMIO writes. It's an implementation of a virtual (software) interrupt controller multiplexing several IPIs over one, hence the atomics stand in for what would be MMIO on a real controller. The actual hardware IPI underlying it all does use a single MMIO read to fetch/mask the event at the controller, but then the tricky ordering is between ACKing that IPI itself (which is a write) and the virtual stuff on top. Spurious hardware IPIs are possible in this model, and are taken care of by the atomic flags being the source of truth for what is actually pending downstream; what I need to make sure to avoid is the opposite case where a virtual IPI ends up pending and unmasked, but the hardware IPI is not correctly raised due to a race. For additional fun: this SoC supports a completely separate "fast IPI" mechanism built on IMP-DEF system registers without any MMIO, which requires ordering against not loads and stores, but rather sysregs. I have no idea if this stuff is formally defined in the architecture in any strict sense (especially since this is IMP-DEF), but I'm probably going to have to run some litmus-style experiments to see how the CPU behaves in practice. Right now we don't use/support this mechanism; that will come later. Still just has one IPI per CPU though, so it won't let us get rid of the virtual stuff on top. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel