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 B0BB5211B85DE for ; Thu, 24 Jan 2019 03:28:44 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 676A77FD67; Thu, 24 Jan 2019 11:28:43 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-237.rdu2.redhat.com [10.10.120.237]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F9C726E66; Thu, 24 Jan 2019 11:28:15 +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> <9BD73EA91F8E404F851CF3F519B14AA8036C67B5@DGGEMI521-MBX.china.huawei.com> From: Laszlo Ersek Message-ID: <6330a9aa-06ee-d3db-add2-09e2ab20bd93@redhat.com> Date: Thu, 24 Jan 2019 12:28:14 +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: <9BD73EA91F8E404F851CF3F519B14AA8036C67B5@DGGEMI521-MBX.china.huawei.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 24 Jan 2019 11:28:43 +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 11:28:44 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/24/19 10:25, 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 > > I retest it with a CPU which have 46 physical address bit and it works well with 1TB aperture, > so it is sure that the inappropriate CPU I used lead to this question. > > BTW, it seems that the OVMF boots successfully with 40 phys addr bits CPUs if I prevent QEMU from > loading iPXE rom. I'm curious about why it works well(at least no problem in the booting stage) > without the iPXE rom. That's a good question; perhaps iPXE touches those high GPAs for some reason. I think we'd have to rebuild the oprom with detailed debug logs enabled to see more. Thanks Laszlo > Anyway, thank you for your nice explanation very much. > > Thanks, > Wu Zongyong >