From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.3515.1610640197236364850 for ; Thu, 14 Jan 2021 08:03:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aEQQ34tN; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610640196; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+ctvK8AQipx9U6IAKKqD9YyOkPMLbfdrZ93tO680pfg=; b=aEQQ34tN454bFQGoCwEVA5q6XA0388uInsdPpdXTUO8pUBQpY2WEH15c1mpZ6eia0p+yXR TF0gd/6qbf8Cmrxd7KqUCCKEaecEAT7LwJXATRUYkmOqPNs87ix+9vLhDINiVnDzw4T6Xj e2JojaxHlUV0gia+wqE3sFkZ8zKVTYo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-339-ajRAGYiyNzWX6BOs335yPA-1; Thu, 14 Jan 2021 11:03:12 -0500 X-MC-Unique: ajRAGYiyNzWX6BOs335yPA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D4794107ACFA; Thu, 14 Jan 2021 16:03:09 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-194.ams2.redhat.com [10.36.112.194]) by smtp.corp.redhat.com (Postfix) with ESMTP id CEF1D10023B9; Thu, 14 Jan 2021 16:03:06 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v4 7/9] OvmfPkg/PciHostBridgeUtilityLib: Extend parameter list of GetRootBridges To: Jiahui Cen , devel@edk2.groups.io Cc: Jordan Justen , Ard Biesheuvel , Rebecca Cran , Peter Grehan , Anthony Perard , Julien Grall , Leif Lindholm , Sami Mujawar , xieyingtai@huawei.com, wu.wubin@huawei.com, Yubo Miao References: <20210112094549.10238-1-cenjiahui@huawei.com> <20210112094549.10238-8-cenjiahui@huawei.com> <28c4d432-f281-91dc-1b93-faf67297f181@redhat.com> From: "Laszlo Ersek" Message-ID: <66ff674c-95a1-2ba0-10c5-44130068c917@redhat.com> Date: Thu, 14 Jan 2021 17:03:05 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/14/21 13:44, Jiahui Cen wrote: > On 2021/1/14 18:46, Laszlo Ersek wrote: >> (7) You missed replacing PCI_MAX_BUS with BusMax here. (But it belongs >> in the separate patch that will deal with the bus numbers, and only with >> the bus numbers.) >> >> ... Which in turn makes me ask you to please test your changes more >> carefully. I believe this bug here is actually shown in the firmware >> debug log. Namely, the "virt" machine type only supports buses 0x0..0xf, >> inclusive (if I remember correctly), because its MMCONFIG space is quite >> limited. >> > > I tested on QEMU for x86_64 and aarch64, and it actually worked well so that > I missed this issue. IIUC, for aarch64, the virt machine supports bus range > [0x0, 0xff] by default, and the MMCONFIG space size is 256MB. Thanks for the reminder -- now I remember this MMCONFIG size depends on the "highmem" machine type property. Indeed it should be "on" for aarch64 by default; it's still "off" for 32-bit ARM (and ArmVirtQemu supports 32-bit ARM as well). Thanks Laszlo