qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3] fw/msr_feature_control: add support to set M


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL
Date: Thu, 7 Jul 2016 15:19:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]