From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4QWW-0002W2-Br for qemu-devel@nongnu.org; Mon, 05 Mar 2012 00:31:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4QWU-0000J7-4B for qemu-devel@nongnu.org; Mon, 05 Mar 2012 00:31:51 -0500 Received: from usrksweb02.endace.com ([174.143.168.194]:47882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4QWT-0000GY-UL for qemu-devel@nongnu.org; Mon, 05 Mar 2012 00:31:50 -0500 Message-ID: <4F544F9A.8040103@endace.com> Date: Mon, 5 Mar 2012 18:31:06 +1300 From: Alexey Korolev MIME-Version: 1.0 References: <1330581043.29508.61.camel@nzhmlwks0057.ad.endace.com> <1330585052.29508.114.camel@nzhmlwks0057.ad.endace.com> <4F4F3FBE.7030202@redhat.com> <4F4FF1AC.40601@endace.com> <4F5074FC.3080500@redhat.com> In-Reply-To: <4F5074FC.3080500@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH 4/6] Mapping of BARs and Bridge regions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: sfd@endace.com, seabios@seabios.org, mst@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On 02/03/12 20:21, Gerd Hoffmann wrote: > On 03/01/12 23:01, Alexey Korolev wrote: >> On 01/03/12 22:22, Gerd Hoffmann wrote: >>> On 03/01/12 07:57, Alexey Korolev wrote: >>>> In pci_bios_map_regions() we try to reserve memory for >>>> all entries of root bus regions. >>>> If pci_bios_init_root_regions() fails - e.g no enough space, we create two new pci_regions: >>>> r64pref, r64mem and migrate all entries which are 64bit capable to them. Migration process >>>> is very simple: delete the entry from one list add to another. >>> It isn't that simple. There are a bunch of constrains. First the >>> bridge must be 64bit capable. All bridges up to the root bus in case of >>> nested bridges. Second all other prefmem bars of devices behind the >>> bridge must be 64bit capable too. Again, in case of nested bridges this >>> applies to all devices behind the toplevel bridge. >> It must be simple as we derive 64bit flag from devices behind the bridge at the stage of building topology. >> >> In other words if the entry at the stage of mapping has 64bit flag it means that the entry and all >> the entries behind it are 64bit capable. >> >> + for (i = (MaxPCIBus + 1) * PCI_REGION_TYPE_COUNT ; i < 0; i--) { >> + ................. >> + is64bit = this_entry->is64bit; >> + size = 0; >> + foreach_region_entry(®ions[i-1], entry) { >> + size += entry->size; >> + is64bit &= entry->is64bit; >> + } >> ................. >> + this_entry->is64bit = is64bit; > This pass looks at the children and clears the is64bit in the parent in > case one of the children isn't 64bit capable. > > I think you need a second pass here, clearing the is64bit in all > children in case the parent has is64bit cleared. It is unnecessary since the parent is not 64bit capable - both the parent and its children would never be mapped to 64bit range. One thing is missing in my code is reading bridge capabilities - so I've added it. > cheers, > Gerd >