> >> (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 > >> > >> <interface type='network'> > >> <rom enabled='no'/> > >> </interface> > >> > >> 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 > <https://bugzilla.redhat.com/show_bug.cgi?id=1353591#c8>, 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. Anyway, thank you for your nice explanation very much. Thanks, Wu Zongyong _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
