From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 54312203BEA30 for ; Thu, 3 May 2018 12:02:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BAEA77CBBA; Thu, 3 May 2018 19:02:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-135.rdu2.redhat.com [10.10.121.135]) by smtp.corp.redhat.com (Postfix) with ESMTP id 434E911166E0; Thu, 3 May 2018 19:02:18 +0000 (UTC) To: Roman Bacik Cc: edk2-devel@lists.01.org, Ruiyu Ni , Vladimir Olovyannikov References: <45404ff573f49b7807e06e0462ab4018@mail.gmail.com> From: Laszlo Ersek Message-ID: Date: Thu, 3 May 2018 21:02:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <45404ff573f49b7807e06e0462ab4018@mail.gmail.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 03 May 2018 19:02:19 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 03 May 2018 19:02:19 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH v2] MdeModulePkg/Bus: Enable ascending resource list X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 19:02:21 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/03/18 17:23, Roman Bacik wrote: > [...] Let me quote the two sets of assignments: - current (not working for you): > PciBus: Resource Map for Bridge [00|00|00] > Type = PMem32; Base = 0x60B00000; Length = 0x100000; Alignment = 0xFFFFF > Base = 0x60B00000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|03:18]; Type = PMem64 > Base = 0x60B20000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|02:18]; Type = PMem64 > Base = 0x60B40000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|01:18]; Type = PMem64 > Base = 0x60B60000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|00:18]; Type = PMem64 > Base = 0x60B80000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|03:10]; Type = PMem64 > Base = 0x60B90000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|02:10]; Type = PMem64 > Base = 0x60BA0000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|01:10]; Type = PMem64 > Base = 0x60BB0000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|00:10]; Type = PMem64 > Base = 0x60BC0000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|03:20]; Type = PMem64 > Base = 0x60BC1000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|02:20]; Type = PMem64 > Base = 0x60BC2000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|01:20]; Type = PMem64 > Base = 0x60BC3000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|00:20]; Type = PMem64 - desired (working for you): > PciBus: Resource Map for Bridge [00|00|00] > Type = PMem32; Base = 0x60000000; Length = 0x100000; Alignment = 0xFFFFF > Base = 0x60000000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|00:18]; Type = PMem64 > Base = 0x60020000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|01:18]; Type = PMem64 > Base = 0x60040000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|02:18]; Type = PMem64 > Base = 0x60060000; Length = 0x20000; Alignment = 0x1FFFF; Owner = PCI [01|00|03:18]; Type = PMem64 > Base = 0x60080000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|00:10]; Type = PMem64 > Base = 0x60090000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|01:10]; Type = PMem64 > Base = 0x600A0000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|02:10]; Type = PMem64 > Base = 0x600B0000; Length = 0x10000; Alignment = 0xFFFF; Owner = PCI [01|00|03:10]; Type = PMem64 > Base = 0x600C0000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|00:20]; Type = PMem64 > Base = 0x600C1000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|01:20]; Type = PMem64 > Base = 0x600C2000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|02:20]; Type = PMem64 > Base = 0x600C3000; Length = 0x1000; Alignment = 0xFFF; Owner = PCI [01|00|03:20]; Type = PMem64 In both listings, the alignment decreases, and the base address increases. So there's no difference between the current and the desired behaviors in that regard. There is one difference though, in the Owner column. Your platform requirement seems to be: For all (Bus, Device, RegionN): if ((FunctionA < FunctionB) && (Size(Bus.Device.FunctionA.RegionN) == Size(Bus.Device.FunctionB.RegionN))) then (Base(Bus.Device.FunctionA.RegionN) < Base(Bus.Device.FunctionB.RegionN)) This is a very strange requirement. It means that for any PCI device that has (at least) two functions, such that both functions have the same RegionN with identical size, the function with lower number must receive a lower base address for RegionN. Is my understanding correct? If it is, then it should be enough to refine the sorting in InsertResourceNode(). Namely, introduce the PCI B/D/F triplet as the "least significant" component for the sorting, such that it decide about ordering only when the resource sizes are equal. I *guess* the PCI B/D/F can be reached via PCI_RESOURCE_NODE.PciDev->{BusNumber,DeviceNumber,FunctionNumber}. If that works, the next question is how to expose this platform quirk. Perhaps Ray will prefer a PCD, or else an addition to the PI spec, which already defines EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL (but can't cover the above requirement yet, AFAICS). Thanks Laszlo