From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL9Dm-0003hc-Ie for qemu-devel@nongnu.org; Thu, 07 Jul 2016 09:20:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL9Dg-0004A6-ES for qemu-devel@nongnu.org; Thu, 07 Jul 2016 09:20:01 -0400 Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:33014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL9Dg-00049r-7g for qemu-devel@nongnu.org; Thu, 07 Jul 2016 09:19:56 -0400 Received: by mail-wm0-x243.google.com with SMTP id n127so2908896wme.0 for ; Thu, 07 Jul 2016 06:19:55 -0700 (PDT) Sender: Paolo Bonzini References: <20160622065324.23812-1-haozhong.zhang@intel.com> <20160706012619.ebiizdoqngkmur7a@hz-desktop> <234271213.4215596.1467785884526.JavaMail.zimbra@redhat.com> <20160706062832.py2denwwvhw24f52@hz-desktop> <395937dc-b61d-880c-8a62-545bfc88eb84@redhat.com> <761279c8-3386-398e-f76f-919e55a81b06@redhat.com> <2af5d48b-4bcc-d25d-e41e-5c41cf74b631@redhat.com> <4421d34d-e318-b1c6-08bc-3cd7800e5dd8@redhat.com> <678512723.4663298.1467893526100.JavaMail.zimbra@redhat.com> <097347c2-eecf-373c-3a05-a15d98ec1733@redhat.com> From: Paolo Bonzini Message-ID: <23a66f14-fcb2-97ac-120b-954da222219f@redhat.com> Date: Thu, 7 Jul 2016 15:19:52 +0200 MIME-Version: 1.0 In-Reply-To: <097347c2-eecf-373c-3a05-a15d98ec1733@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] fw/msr_feature_control: add support to set MSR_IA32_FEATURE_CONTROL List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: seabios@seabios.org, Ashok Raj , qemu-devel@nongnu.org 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