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 E2811D80D4E for ; Wed, 1 Nov 2023 20:17:28 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=cLX09CerM+rD0HQ3oh4/MBfuBwXeBuBlxzbDIRUnW3c=; c=relaxed/simple; d=groups.io; h=Subject:To:From:User-Agent:MIME-Version:Date:References:In-Reply-To:Message-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1698869847; v=1; b=UnA1tziojabV2LM6JI6KFlmX2On9EUQBcGvOCQe4xfIP16G7x/TrTkMv9odXfVXYyoiWGaTK j+8Gs8TnL4inYSaZ5pQWjtILzdBzq7E35CZjuD43a/clWTC7UFGKRsYnBwj2awHoUn9pTtMMLxt JYrETdahgZ2hZMRQIuGxBI6I= X-Received: by 127.0.0.2 with SMTP id L7hDYY7687511xx9eGqfstAA; Wed, 01 Nov 2023 13:17:27 -0700 Subject: Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations To: Ard Biesheuvel ,devel@edk2.groups.io From: "Joe L" X-Originating-Location: Seattle, Washington, US (97.126.119.134) X-Originating-Platform: Windows Chrome 118 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 01 Nov 2023 13:17:27 -0700 References: In-Reply-To: Message-ID: <6575.1698869847229215662@groups.io> 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,jlotwo@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: ZWwoTEtntpgsZytaTErxBEJ3x7686176AA= Content-Type: multipart/alternative; boundary="5nyBUi8vn98DAi92jMMp" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=UnA1tzio; 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) --5nyBUi8vn98DAi92jMMp Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the discussion, Are we saying that DataSynchronizationBarrier () before the return from Roo= tBridgeIoPciAccess() is not strong enough to determine that the final ECAM = write would have completed? According to Learn the architecture - ARMv8-A m= emory systems ( https://developer.arm.com/documentation/100941/0101/Barrier= s ) the DSB should block "execution of any further instructions, not just l= oads or stores, until synchronization is complete". To me this means that f= or Arm the DSB will stall any subsequent instructions until the completion = for the ECAM write is received by the processor. Though if an architecture-agnostic solution is desired the readback before = returning from RootBridgeIoPciAccess() does make sense. If the access spann= ed multiple DWORDs then should a read from the final aligned DWORD in the "= buffer" be sufficient? -=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 (#110489): https://edk2.groups.io/g/devel/message/110489 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- --5nyBUi8vn98DAi92jMMp Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks for the discussion,

Are we saying that DataSynchronizationBarrier () before = the return from Root= BridgeIoPciAccess() is not strong enough to determine that the final ECAM w= rite would have completed? According to Learn the architecture - ARMv8= -A memory systems the DSB should block "execution of any further instru= ctions, not just loads or stores, until synchronization is complete". To me= this means that for Arm the DSB will stall any subsequent instructions unt= il the completion for the ECAM write is received by the processor.
Though if an architecture-agnostic solution is desired the readback befo= re returning from Root= BridgeIoPciAccess() does make sense. If the access spanned multiple = DWORDs then should a read from the final aligned DWORD in the "buffer" be s= ufficient?

 

_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#110489) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--5nyBUi8vn98DAi92jMMp--