From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 E5B2F21EA35C8 for ; Tue, 5 Sep 2017 00:41:42 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id j141so7826855ioj.4 for ; Tue, 05 Sep 2017 00:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FrHryfE2NlUN1qKxjS2KaS8Ta1oMlAbnLS1xDpQc5S4=; b=mX5MwNjJZprdloYAQSH6rgmJHI4W84OnJ4P1Iwwa0h5WnYIe/ISYfTGq5rr/bcSDF5 t+FZM5vO8gSBwaMLM3MSiM2CM+/WS5aGjE+2Y/cT+60nnBzed2xTnxGDjoqWMgwN6yhg Olc/ljhuwG+5mGK1EVOwds/jzNqSPIh2k6Fkh21vUlFojeiaGUfyAljIoh0yQHnQfbm8 P3a/m/DPWii8PCWHwJE5FW3KTPDHBU1Ct/drLSPJhoM6EDvugMjJJm+Xj10mmkoK+dUK fSJMPJdNvUbZoBuPF8maJ53x/rExJID69+N19KrppssKvG7v4OY2cI7ut6AUZz9mWMa/ 9HJA== 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; bh=FrHryfE2NlUN1qKxjS2KaS8Ta1oMlAbnLS1xDpQc5S4=; b=rkgM/gQpAmHjHJOTz8IAQ2GSyWFEA8H04grk1VXIwk1fIKuLh2lqhm++e/ph31fiky 5uSecuxFaUV0T4km3o0nkLvpMCASe+3JIxfzB0JvpGrNblWFkYvflgHZ+rrxu2xDUqqc F8pRcg8fTCqU9oJO78wM4vyPq3OhHXklCSvrVJHzQddihRPEInVW/hRJ377v45frMqGU Xr04R6bljAFprxFKpy3Iq9MRf1sNfOUdujtfUPCLXcrn/vd9ptEHIBpXjmR1JQbML4+R 4wCzmDIvowqi711fyKg0H+jWGtiUshdWVSAFY5Q2jfEish1YdjCSJAit7SApIuaiG7o3 3vHQ== X-Gm-Message-State: AHPjjUj8mfSY3p5qqOuyzyeCiJ9EVdiVGL4MvezXFiqxsSEwRuoDWpFn IIKR/i/dUgTzCfquSlZgTuy1lYcekkvf X-Google-Smtp-Source: ADKCNb404BlVFVD7V/L5FlNxgNqjBHiV0sofPwQabI4SwSWjXlG4mczqIXF4vxiACue8CnEJjK2YP88JulAXtiSKBUA= X-Received: by 10.36.139.3 with SMTP id g3mr3019337ite.32.1504597471023; Tue, 05 Sep 2017 00:44:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.0.150 with HTTP; Tue, 5 Sep 2017 00:44:30 -0700 (PDT) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BA23CEF@SHSMSX104.ccr.corp.intel.com> References: <734D49CCEBEEF84792F5B80ED585239D5BA23CEF@SHSMSX104.ccr.corp.intel.com> From: Bartosz Szczepanek Date: Tue, 5 Sep 2017 09:44:30 +0200 Message-ID: To: "Ni, Ruiyu" Cc: "edk2-devel@lists.01.org" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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 07:41:43 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ray, thanks for your answer. This makes sense to me, but I still see some inconsistency in regard to specification. UEFI spec says: > Address Range Minimum. Starting address of a BAR. and then > Address Translation Offset. Offset to apply to the Starting address of a > BAR to convert it to a PCI address. If it's needed to apply AddrTranslationOffset to AddrRangeMin to convert it *to a PCI address*, how can it be a PCI (device) address already? To me it seems like a discrepancy between UEFI specification and what industry does. Please let me know what is your understanding of the snippets above, if this is a mistake in spec it would be great to agree on that and request appropriate correction. Best regards, Bartosz PS =E2=80=93 I wrote PciIoGetAttributes in last mail instead of PciIoGetBarAttributes, sorry for the mistake. 2017-09-05 9:07 GMT+02:00 Ni, Ruiyu : > Bartosz, > > > > Based on your findings, the AddrRangeMin has to be a device addressJ > > > > 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 > AddressTranslationOffset field was used. > > To avoid breaking the existing consumers, GetBarAttributes() remains to > return the BAR address. > > > > Anyone please correct me if I am wrong. > > > > Thanks, > > Ray > > > > *From:* Bartosz Szczepanek [mailto:bsz@semihalf.com] > *Sent:* Monday, September 4, 2017 7:43 PM > *To:* edk2-devel@lists.01.org > *Cc:* Ni, Ruiyu > *Subject:* [edk2] CPU/PCI addressing in PciIoGetAttributes > > > > Hi guys, > > > > I have some doubt about PciIoGetAttributes behaviour on aarch64 platform > with non-uniform CPU:PCI address space mapping. I'll be grateful if you > verify my understanding. > > > > According to UEFI specification, AddrRangeMin in QWORD Address Space > Descriptor returned by PciIoGetAttributes() should be a CPU address, at > least that's what I conclude from: > > > Address Translation Offset. Offset to apply to the Starting address of = a > > > BAR *to convert it to a PCI address*. This value is zero unless the > > > HostAddress and DeviceAddress for the BAR are different. > > This mentions "Starting address", which I suppose refers to AddrRangeMin. > It needs to be converted to PCI address, so as-is it should be in CPU > address space. > > > > On the other hand, the AddrRangeMin is assigned BaseAddress value obtaine= d > directly from PciBar: > > > Descriptor->AddrRangeMin =3D PciIoDevice->PciBar[BarIndex].BaseAddress; > > > > PciBar is filled in PciParseBar() using original BAR content (thus > BaseAddress is not translated, PCI address). This way value that refers t= o > PCI space is returned from PciIoGetBarAttributes as CPU address. > > > > Shouldn't there be translation of it somewhere on the way? Or is my > understanding flawed? Either way, please let me know. > > > > Best regards, > > Bartosz >