mirror of https://github.com/acidanthera/audk.git
1cbd833089
According to the Intel SDM (325462-060US / September 2016), > INPUT EAX = 0BH: Returns Extended Topology Information > > [...] Software must detect the presence of CPUID leaf 0BH by verifying > (a) the highest leaf index supported by CPUID is >= 0BH, and > (b) CPUID.0BH:EBX[15:0] reports a non-zero value. [...] The "GetApicId" sections in the Ia32 and X64 "MpFuncs.nasm" files do not perform check (b). This causes an actual bug in the following OVMF setup: - Intel W3550 host processor <http://ark.intel.com/products/39720/>, - the QEMU/KVM guest's VCPU model is set to "host", that is, "the CPU visible to the guest should be exactly the same as the host CPU". Under "GetApicId", check (a) passes: the CPUID level of the W3550 is exactly 11 decimal. However, leaf 11 itself is not supported, therefore EDX is set to zero: > If a value entered for CPUID.EAX is less than or equal to the maximum > input value and the leaf is not supported on that processor then 0 is > returned in all the registers. Because we don't check (b), the "GetProcessorNumber" section of the code is reached with an initial APIC ID of 0 in EDX on all of the APs. Given that "GetProcessorNumber" searches the "MP_CPU_EXCHANGE_INFO.CpuInfo[*].InitialApicId" fields for a match, all APs enter ApWakeupFunction() with an identical "NumApsExecuting" parameter. This results in unpredictable guest behavior (crashes, reboots, hangs etc). Reorganize the "GetApicId" section and add the missing check in both assembly files. Cc: Jeff Fan <jeff.fan@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> |
||
|---|---|---|
| .. | ||
| MpEqu.inc | ||
| MpFuncs.nasm | ||