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 0F497941C6A for ; Wed, 1 Nov 2023 21:51:07 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=57SodWiv3tIYXimUD5EjTvEbgDfzExXJu/zPGx6SFDI=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:To:References:From:Subject:In-Reply-To:Feedback-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698875466; v=1; b=MSqeGvh1woPsm8VOkhfVjx+54PFN/JYJShcPq5srlDBm0Fq/ItiiosroCMQXYCReo5ypGWx5 kNxX2a0ZcJ4LitUZrkd6v4Q4HCVbvoysVle+ve0Tg340a0DJqQEdGXNICHFOl+1DWT1hC/KQAef 3eh5chWKmmynAlE+/nX9XhsY= X-Received: by 127.0.0.2 with SMTP id 3sNjYY7687511xQ6mf85PqjP; Wed, 01 Nov 2023 14:51:06 -0700 X-Received: from a7-18.smtp-out.eu-west-1.amazonses.com (a7-18.smtp-out.eu-west-1.amazonses.com [54.240.7.18]) by mx.groups.io with SMTP id smtpd.web11.731.1698875465631255700 for ; Wed, 01 Nov 2023 14:51:06 -0700 Message-ID: <0102018b8cde55ad-1703490f-ed69-4b5a-81dc-9bf2a378d064-000000@eu-west-1.amazonses.com> Date: Wed, 1 Nov 2023 21:51:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: devel@edk2.groups.io, jlotwo@gmail.com, Ard Biesheuvel References: <6575.1698869847229215662@groups.io> From: "Michael Brown" Subject: Re: [edk2-devel] [RFC] Ordering of Arm PCI ECAM and MMIO operations In-Reply-To: <6575.1698869847229215662@groups.io> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Feedback-ID: 1.eu-west-1.fspj4M/5bzJ9NLRzJP0PaxRwxrpZqiDQJ1IF94CF2TA=:AmazonSES X-SES-Outgoing: 2023.11.01-54.240.7.18 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,mcb30@ipxe.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 20DlnADwLAoHfnxMIrBtFI04x7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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=MSqeGvh1; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 01/11/2023 20:17, Joe L wrote: > Thanks for the discussion, >=20 > Are we saying that DataSynchronizationBarrier () before the return=20 > from RootBridgeIoPciAccess() is not strong enough to determine that=20 > the final ECAM write would have completed? According to Learn the=20 > architecture - ARMv8-A memory systems=20 > the=20 > DSB should block "execution of any further instructions, not just=20 > 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=20 to the target PCIe device (as opposed to e.g. completing as far as the=20 host bridge, or to an intermediate PCIe bridge). I don't know the answer, and it feels like the kind of messy area where=20 adding a barrier will definitely reduce the probability of the issue=20 occurring but might not guarantee a fix, which is a bad situation to be=20 left in. > Though if an architecture-agnostic solution is desired the readback=20 > before returning from RootBridgeIoPciAccess() does make sense. Personally I like having an architecture-agnostic solution, and I'll be updating the ECAM driver in iPXE to use the readback approach. > If the access spanned multiple DWORDs then should a read from the=20 > final aligned DWORD in the "buffer" be sufficient? Quite possibly. Given that PCIe configuration space accesses are never=20 performance-critical, I'm not sure it's worth the optimisation, but I'll=20 defer to the people who actually have to implement it in EDK2. Thanks, Michael -=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 (#110493): https://edk2.groups.io/g/devel/message/110493 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-