From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 9ACAB21CEB0FE for ; Mon, 11 Sep 2017 23:41:07 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v19so20736310ite.0 for ; Mon, 11 Sep 2017 23:44:04 -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; bh=ptKhytQL9kDdoyH7xZ9os8bavJOeaCv4BaQJTYbzGPc=; b=jOI1Md9Mc4TQThgAIfWvELz50hzr1qsLKDoQuGX8oN125wSzhnsz3zNHAhg0ZzvFmJ EJ+vjhjHbTbPdakxh1pi2fyodSbZSsyaS9bsSB1rfLyVZiLUen0rsV+F7LVQ4dAliKN4 ej0ZEhN9BwFac6XcCXIB1jUYXvo96AmH1257k= 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=ptKhytQL9kDdoyH7xZ9os8bavJOeaCv4BaQJTYbzGPc=; b=BPFxjhJyqC49d3OJSNtyRoiRE0toLeJasS7hLVCpEb0r5GGV2qjeYrGUraJIcC5BTF tpbbWgC2enSAQHq5Y/rhmAmZ6mzxpQBJ2IwOiYZ6tDooK7n2Nl6iSxBtHVwlnqYK8suE wlDS8174VaR2y27ROBhDBtDUJ7SziSQtvFvjPzJVIqCQDQ9VuqYCRPrYMehQBJDk2Oto /ddXotXvnFf6cArmIvSIij/b1XUaU/x1vRLaxvlnz25Oc1seQLeqVUyeXkoywNkc4ba7 AvCRVLdFLgQwwVMX/UVlFF6/mQ7XSwgmNmatdGSBBlEAN32VkLOoEDOJIb+y5SS1ktnt DPMA== X-Gm-Message-State: AHPjjUiV1SBmzB0LdaU56VS2inmfWi/Jz5FZ5VZHqgp5FmZPv1Dw0fAi h6HcE8+oWh4ihpnOH4bfi7bi0GcQni2m X-Google-Smtp-Source: AOwi7QAtBjP3w1pz9UtNMCiFMNjqkXCy2nl7PZAg+AaByxcqAzLtWkCKE68ri5A+wLDRTzo25trrfGJsTg1YD2TrYf8= X-Received: by 10.36.50.150 with SMTP id j144mr16617092ita.52.1505198643452; Mon, 11 Sep 2017 23:44:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Mon, 11 Sep 2017 23:44:02 -0700 (PDT) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BA2BABB@SHSMSX104.ccr.corp.intel.com> References: <20170911050121.85708-1-ruiyu.ni@intel.com> <7fbd6e6b-0577-f470-3e89-f785ddd5dee1@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5BA2BABB@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Tue, 12 Sep 2017 07:44:02 +0100 Message-ID: To: "Ni, Ruiyu" Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , Dong Wei , Benjamin Herrenschmidt , Andrew Fish Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: GetBarAttributes() returns Host address 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, 12 Sep 2017 06:41:07 -0000 Content-Type: text/plain; charset="UTF-8" On 12 September 2017 at 06:01, Ni, Ruiyu wrote: > Laszlo, > Your understanding is: DeviceAddress = HostAddress + AddressTranslationOffset > But my patch assumes: HostAddress = DeviceAddress + AddressTranslationOffset > > They are totally different. If I follow your understanding, the patch is wrong! > Since UEFI spec doesn't describe "apply to" in sentence " Offset to apply to the > Starting address of a BAR to convert it to a PCI address" very clearly, I quoted > the statement from ACPI spec. > Your understanding to "apply to" is "add", my understanding is "minus". > Even though we are stretching the ACPI definition of a QWord descriptor beyond its original meaning, I don't think there is a lot of ambiguity here, to be honest. The AddrRangeMin field contains the address on the secondary side of a bridge, and the primary value can be obtained by 'applying' the ATO. In my opinion, applying a (positive or negative) offset implies addition, not subtraction, as subtraction involves negating the second addend before applying it. And the secondary side of the host bridge is clearly the PCI side. It does mean the offset field is signed, though. So I don't agree with the conclusion that no clarification is required. We need to make sure the spec is crystal clear in this regard. But I do agree with the change, I think it is the only solution that makes sense.