On 02/28/16 08:16, Ni, Ruiyu wrote: >>> 在 2016年2月27日，下午6:17，Laszlo Ersek <ler...@redhat.com> 写道：
>> Thus, this argument comprises two parts: >> >> 1. PciHostBridgeDxe needs to use a platform dependent config space >> limit: 0xFF, 0xFFF, or something else that matches the platform's >> PciSegmentLib instance. Correcting this bug is not optional, it is >> unavoidable. Hard-coding an ECAM assumption in the driver is a bug. > You didn't convince me here but given the fact you told me that qemu > is too old to support pci express way access, Small clarification: the "motherboard (chipset) services" that QEMU provides *vary*. First, you have to pick an architecture to emulate (i386, x86_64, arm, aarch64, and so on). This is called "target". The different targets are built into different QEMU executables. For system emulation, they look like: - qemu-system-x86_64 - qemu-system-aarch64 - etc Once you picked the binary (i.e., you selected the target), QEMU provides several "machine types" for that target. The targets can be listed with "-machine help": $ qemu-system-x86_64 -machine help Supported machines are: pc Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-2.6) pc-i440fx-2.6 Standard PC (i440FX + PIIX, 1996) (default) pc-i440fx-2.5 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.4 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.3 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.2 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.1 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.0 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.7 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.6 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.5 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) pc-1.3 Standard PC (i440FX + PIIX, 1996) pc-1.2 Standard PC (i440FX + PIIX, 1996) pc-1.1 Standard PC (i440FX + PIIX, 1996) pc-1.0 Standard PC (i440FX + PIIX, 1996) pc-0.15 Standard PC (i440FX + PIIX, 1996) pc-0.14 Standard PC (i440FX + PIIX, 1996) pc-0.13 Standard PC (i440FX + PIIX, 1996) pc-0.12 Standard PC (i440FX + PIIX, 1996) pc-0.11 Standard PC (i440FX + PIIX, 1996) pc-0.10 Standard PC (i440FX + PIIX, 1996) q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.6) pc-q35-2.6 Standard PC (Q35 + ICH9, 2009) pc-q35-2.5 Standard PC (Q35 + ICH9, 2009) pc-q35-2.4 Standard PC (Q35 + ICH9, 2009) pc-q35-2.3 Standard PC (Q35 + ICH9, 2009) pc-q35-2.2 Standard PC (Q35 + ICH9, 2009) pc-q35-2.1 Standard PC (Q35 + ICH9, 2009) pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) isapc ISA-only PC none empty machine You can identify two facts from this output. First, some machine types are versioned. This is related to migration compatibility, and not very interesting here. The other fact is that there are two machine type "families", i440fx, and q35. Those are quite different. i440fx is the older machine type. It lacks a number of things that Q35 provides. For example: - it lacks ECAM / MMCONFIG - it also lacks SMM. (Remember <http://thread.gmane.org/gmane.comp.bios.edk2.devel/8078>?) Q35 is the newer, more modern machine type. It does have ECAM / MMCONFIG, but Q35 is not the default machine type. i440fx is way more "mature"; it is almost universally used by users. For example, our own RHEL-7.2 release does not officially support Q35 machine types. Hence, the clarification I'd like to make is: QEMU (the project) is definitely not too old to support ECAM. Instead, the i440fx machine type in particular, emulated by QEMU, is too old (2016 - 1996 = 20 years). For another example, the "virt" machine type of "qemu-system-aarch64" emulates ECAM as well. (And "ArmVirtPkg/PciHostBridgeDxe" uses ECAM.) So, it is not QEMU in general that is limited to 0xCF8 / 0xCFC; it is one specific (emulation target, machine type) pair that has this limitation. i440fx happens to be the most widely used machine type. I'm not aware of any specific plans or timeline to switch the default to Q35. > I agree I didn't think > there might be a such old platform. Yes, the virtual hardware of the i440fx machine type mostly reflects 1996, as the help output above says. It is based on the "Intel ® 82371AB PIIX4" and the "Intel ® 440FX PCIset 82441FX (PMC)" specs. The PDFs that I have on my disk for understanding and occasionally developing i440fx are: - document # 290549-001 - document # 290562-001 - document # 297654-006 - document # 297738-017 (They are listed in "OvmfPkg/Include/IndustryStandard/I440FxPiix4.h" as well.) > So enhancing my driver to support > it is acceptable. Thank you. I hugely appreciate it. >> 2. The other question is *whence exactly* this information should come. >> There are several alternatives here; let me list a few: >> >> * Add a new API to PciSegmentLib that returns the limit. > Not good because then pci lib also needs such api. >> >> * Or, add a new API to PciHostBridgeLib that returns the limit. > Intend to use this way. In a extreme case, a platform may contain two > root bridges, one support MMIO cfg space access, the other doesn't. > So we may need to use the way you proposed. But I think a flag is > enough rather than a aperture range. Did you see platform that has > range other than [0,ff] [0,fff]? I'm not aware of anything different from 0x0-0xff and 0x0-0xfff. Therefore a simple boolean flag (per root bridge structure) could do the job indeed. I will update my patch and submit it separately, for your review. >> >> * Or, add a new PCD that communicates the limit. >> >> * Or, in the driver, investigate PcdPciExpressBaseAddress (which is >> the central PCD for the base of the MMCONFIG / ECAM area). If the >> value is MAX_UINT64 -- which is obviously unusable as ECAM --, then >> assume a limit of 0xFF. Otherwise, assume 0xFFF. > A multi segment platform may also set such PCD to an invalid value because > there are multiple base addresses. Good point! Thank you! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
