On 07/07/2016 14:44, Laszlo Ersek wrote: > Regarding MTRRs... that's a bit messy. PlatformPei only progams the > MTRRs only on the BSP. For the normal boot path, this is no problem, > because when EFI_MP_SERVICES_PROTOCOL starts up (in CpuDxe), the MTRR > settings are broad-cast to all APs. It is also not a problem for the S3 > resume path, when the SMM driver stack is used, because CpuS3DataDxe > saves the MTRRs at End-of-DXE, and at S3 resume, PiSmmCpuDxeSmm restores > them. > > There is one path where the firmware does not restore MTRRs on APs: S3 > resume without the SMM driver stack. In practice this doesn't seem to > cause problems. Maybe Linux restores those MTRRs anyway, when the APs > are onlined after resume -- even at cold boot, Linux checks the MTRR > config, and if it's inconsistent between BSP and APs, the APs are adapted.
Oh, that helps indeed. > (If I understand correctly, on S3 resume, SeaBIOS doesn't reprogram the > MTRRs even on the BSP, and historically this has caused no problems. So > in that sense OVMF is "no worse". :)) MTRRs hardly have any effect on virt platforms, which kinda explains that. We need to fix that now that smp_setup is used for MSR_IA32_FEATURE_CONTROL. Paolo
