From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0D24E21EA35D5 for ; Tue, 5 Sep 2017 06:37:46 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q64so16292789iod.5 for ; Tue, 05 Sep 2017 06:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U8zmlTC0UTIeIOFmRpneMCyUFy9c8yVx47nNRGYCMcY=; b=hn4dC9j2f2O5OwXcNEY7KNyUSRAab2XREK73AsVMVKAwq9bp5vz2JYgbCd21LnwGNx aAtmhdUiWlAa+JF6dqBUQ40LvkE5lhf6Z77RZzCAxhiiNUG5IZZJPFFfxfeH5awR78uI VAaN2Fxew7Ig8XurJ9vkmwyAfNu/t/e5JhPCo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U8zmlTC0UTIeIOFmRpneMCyUFy9c8yVx47nNRGYCMcY=; b=MJArcH9gDt5HqWi5phoSDhdOcnTsBCOJSCy0/oWHu5rLxYNsseMb/lDbfNl5ARKw87 GFJ4ntN8IVKcsaVLropcqVumyHs0ioPVRi4rVNRij0dukNwunl02zG2NakbwT1zSWc0l svmHI7VCcG2h7tNHWxTpXr9JOfXhM700mpG0AEt30ge39y5Ah8TvjcJOgDAultxnDOnv /A6YIoxJHE/cFANcipImsP/x980euRVQWSnWc/zOFy+BAt08yN/qHhhhxBAcURLKyT2e By1b6XgEBL+CEyYPv5qxNpVkPwqt7mPa340LW6ZqcvQK3xRlo2WW5gVJ4a/q8YVtlmRy m34g== X-Gm-Message-State: AHPjjUhe5dFnCZdiJ4B8mbSerYW8sWAs7w+mk0/OmaRDQMXLEOM5asQp LmVruIZSJWv81D4+yLglD5lBQN2lguOp X-Google-Smtp-Source: ADKCNb4hkrH4CoX/h7un7sclPYxNTsIXGMtqloSyf1VV7aBFEQ/0PW5/zV/VPnZpEZlsOwRjfZY753JmIxalenb7wSc= X-Received: by 10.107.142.200 with SMTP id q191mr3954429iod.149.1504618834354; Tue, 05 Sep 2017 06:40:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.1 with HTTP; Tue, 5 Sep 2017 06:40:33 -0700 (PDT) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BA23CEF@SHSMSX104.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BA23CEF@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Tue, 5 Sep 2017 14:40:33 +0100 Message-ID: To: "Ni, Ruiyu" Cc: Bartosz Szczepanek , "edk2-devel@lists.01.org" Subject: Re: CPU/PCI addressing in PciIoGetAttributes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 13:37:46 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 5 September 2017 at 08:07, Ni, Ruiyu wrote: > Bartosz, > > Based on your findings, the AddrRangeMin has to be a device address=E2=98= =BA > > As far as I can remember, this history is: > In the very beginning, Spec owner assumes the device address equals to CP= U address. > The implementation of GetBarAttributes() directly returns the address rea= d from the BAR. > But later we found device address doesn=E2=80=99t equal to CPU address, e= specially in ARM platform. > So in order to expose the offset of the two addresses, the AddressTransla= tionOffset field was used. > To avoid breaking the existing consumers, GetBarAttributes() remains to r= eturn the BAR address. > > Anyone please correct me if I am wrong. > The spec is quite clear: the address descriptor should *not* contain the raw BAR value, but the CPU's translated view. So I think we should fix the implementation to comply with that. The risk for breakage should be low, given that the translation is zero in 99% of the cases anyway, especially on traditional UEFI (PC) platforms.