From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 17EA1211B85DC for ; Thu, 24 Jan 2019 00:21:35 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3E5BD4D81; Thu, 24 Jan 2019 08:21:34 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-37.rdu2.redhat.com [10.10.120.37]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4065C17B55; Thu, 24 Jan 2019 08:21:26 +0000 (UTC) To: "Wuzongyong (Euler Dept)" Cc: "edk2-devel@lists.01.org" , chenlixin , "Wanzongshun (Vincent)" , Alex Williamson , Gerd Hoffmann , "Dr. David Alan Gilbert" References: <9BD73EA91F8E404F851CF3F519B14AA8036C60EF@DGGEMI521-MBX.china.huawei.com> <9BD73EA91F8E404F851CF3F519B14AA8036C66BC@DGGEMI521-MBX.china.huawei.com> From: Laszlo Ersek Message-ID: Date: Thu, 24 Jan 2019 09:21:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9BD73EA91F8E404F851CF3F519B14AA8036C66BC@DGGEMI521-MBX.china.huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 24 Jan 2019 08:21:34 +0000 (UTC) Subject: Re: A VM failed to boot when I changed the gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 08:21:36 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/24/19 03:35, Wuzongyong (Euler Dept) wrote: >> (1) Either way, if you'd like to check whether this issue is specific >> to the iPXE option ROM, you could prevent QEMU from loading the ROM >> image into the NIC's ROM BAR, and retest. The QEMU option for that is >> >> -device virtio-net-pci,[some properties,]romfile='' >> >> The corresponging domain XML element is >> >> >> >> >> >> In this case, virtio-net NICs will be bound by OVMF's built-in >> virtio-net driver (OvmfPkg/VirtioNetDxe). >> > The problem goes away indeed if I prevent QEMU from loading the ROM > image as your guide. So is this problem related to the iPXE option > ROM? While it would seem so, I wouldn't claim that just yet, because: > The physical address bits of CPUs I use is 40. > > host:/home/wzy # grep 'address sizes' /proc/cpuinfo > address sizes : 40 bits physical, 48 bits virtual > address sizes : 40 bits physical, 48 bits virtual > address sizes : 40 bits physical, 48 bits virtual > address sizes : 40 bits physical, 48 bits virtual And, in the logs you attached (and thank yoou for those), we see: > GetFirstNonAddress: Pci64Base=0x10000000000 Pci64Size=0x10000000000 > [...] > PublishPeiMemory: mPhysMemAddressWidth=41 PeiMemoryCap=73748 KB This means that you need *41* physical address bits, not 40. The highest inclusive address in the aperture is 0x1FF_FFFF_FFFF, which needs 41 bits for representation. The reason for setting Pci64Base to 1TB is given in the following, in the GetFirstNonAddress() function [OvmfPkg/PlatformPei/MemDetect.c]: > // > // The 64-bit PCI host aperture should also be "naturally" aligned. The > // alignment is determined by rounding the size of the aperture down to the > // next smaller or equal power of two. That is, align the aperture by the > // largest BAR size that can fit into it. > // > Pci64Base = ALIGN_VALUE (Pci64Base, GetPowerOfTwo64 (Pci64Size)); (You can read more about this calculation in , in particular under point (6).) Looking further at the log, at least one BAR is indeed mapped at 1TB (that is, outside of the GPA range that your host can work with): > Type = Mem64; Base = 0x10000000000; Length = 0x100000; Alignment = 0xFFFFF > Base = 0x10000000000; Length = 0x4000; Alignment = 0x3FFF; Owner = PCI [00|04|00:20]; Type = PMem64 I would suggest retesting on appropriate hardware (41+ phys addr bits), or else decreasing "opt/ovmf/X-PciMmio64Mb", until the OVMF debug log confirms that "mPhysMemAddressWidth" is 40, or less. If the iPXE oprom crashes in that case too, then that would strongly suggest a problem in it. Thanks, Laszlo