From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 9DD16D802AC for ; Wed, 1 Nov 2023 23:08:09 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Cf8ue4bBhgNS9ML3yTiM0elpL4AgxXASy0F4UljunGE=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698880088; v=1; b=uW7n4hJ34h8or/r0SP7xUV9kmFCq55EJGtTFfmboTelyz1YesyT7vQHdf5ksnHnwvtIQQyId aIUavJ04RZucm5PKJOkwWqjVmtXg0Eg6aH9d19qE6xX4vM2VmQg/I5ORD4WAjCN9SMtmL7wyGFE y97UZN5/EXkX6dFgptrPBLh8= X-Received: by 127.0.0.2 with SMTP id MJk8YY7687511xnSZpFnTDqv; Wed, 01 Nov 2023 16:08:08 -0700 X-Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by mx.groups.io with SMTP id smtpd.web11.2496.1698880087775291582 for ; Wed, 01 Nov 2023 16:08:07 -0700 X-Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-45853ab5556so161143137.2 for ; Wed, 01 Nov 2023 16:08:07 -0700 (PDT) X-Gm-Message-State: WLUCijZgbqWAcdtrE0MccDMPx7686176AA= X-Google-Smtp-Source: AGHT+IHIkY2MEzG0eHRWb1mLHeQ4f4jkFVIilwdB18Dh34cNLjHj2jrGSj/OAZe8cCAlqA4ksWYYDE+11rTdDaN07ew= X-Received: by 2002:a05:6102:4712:b0:45b:6d6b:1857 with SMTP id ei18-20020a056102471200b0045b6d6b1857mr11461649vsb.7.1698880086532; Wed, 01 Nov 2023 16:08:06 -0700 (PDT) MIME-Version: 1.0 References: <6575.1698869847229215662@groups.io> <0102018b8cde55ad-1703490f-ed69-4b5a-81dc-9bf2a378d064-000000@eu-west-1.amazonses.com> In-Reply-To: <0102018b8cde55ad-1703490f-ed69-4b5a-81dc-9bf2a378d064-000000@eu-west-1.amazonses.com> From: "Pedro Falcato" Date: Wed, 1 Nov 2023 23:07:54 +0000 Message-ID: Subject: Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations To: devel@edk2.groups.io, mcb30@ipxe.org Cc: jlotwo@gmail.com, Ard Biesheuvel Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,pedro.falcato@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=uW7n4hJ3; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none) On Wed, Nov 1, 2023 at 9:51=E2=80=AFPM Michael Brown wrote= : > > On 01/11/2023 20:17, Joe L wrote: > > Thanks for the discussion, > > > > Are we saying that DataSynchronizationBarrier () before the return > > from RootBridgeIoPciAccess() is not strong enough to determine that > > the final ECAM write would have completed? According to Learn the > > architecture - ARMv8-A memory systems > > the > > DSB should block "execution of any further instructions, not just > > loads or stores, until synchronization is complete". To me this means > > that for Arm the DSB will stall any subsequent instructions until the > > completion for the ECAM write is received by the processor. > > I honestly can't tell from the wording there whether or not DSB would > guarantee that the configuration space write has completed all the way > to the target PCIe device (as opposed to e.g. completing as far as the > host bridge, or to an intermediate PCIe bridge). > > I don't know the answer, and it feels like the kind of messy area where > adding a barrier will definitely reduce the probability of the issue > occurring but might not guarantee a fix, which is a bad situation to be > left in. Given we are working with Device nGnRnE memory, and the documentation says stuff like " This determines whether an intermediate write buffer between the processor and the slave device being accessed is allowed to send an acknowledgement of a write completion. If the address is marked as non Early Write Acknowledgement (nE), then the write response must come from the peripheral. If the address is marked as Early Write Acknowledgement (E), then it is permissible for a buffer in the interconnect logic to signal write acceptance, in advance of the write actually being received by the end device. This is essentially a message to the external memory system." I would expect the write ACK to come from the device itself (I can't wait for the obscure ARM doc that proves me wrong!) --=20 Pedro -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110494): https://edk2.groups.io/g/devel/message/110494 Mute This Topic: https://groups.io/mt/102310377/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-