From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL8AC-00006m-OK for qemu-devel@nongnu.org; Thu, 07 Jul 2016 08:12:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL8A6-0006AB-1l for qemu-devel@nongnu.org; Thu, 07 Jul 2016 08:12:13 -0400 Received: from mx6-phx2.redhat.com ([209.132.183.39]:48706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL8A5-00069D-Pi for qemu-devel@nongnu.org; Thu, 07 Jul 2016 08:12:09 -0400 Date: Thu, 7 Jul 2016 08:12:06 -0400 (EDT) From: Paolo Bonzini Message-ID: <678512723.4663298.1467893526100.JavaMail.zimbra@redhat.com> In-Reply-To: <4421d34d-e318-b1c6-08bc-3cd7800e5dd8@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] [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: Ashok Raj , seabios@seabios.org, qemu-devel@nongnu.org > I've worried that if I only *call* these interfaces to set the MSR, then > the next (independent) use of the same interfaces would clear the MSR > through the INIT-SIPI-SIPI. That would have forced me to modify the > protocol / PPI implementations so that any use of them would reprogram > the MSR every time, after the INIT-SIPI-SIPI. > > This way however (hopefully) it should suffice to call the PPI only -- > the results should survive from PEI to DXE to the runtime OS on the > normal boot path, and from PEI to the runtime OS on the S3 resume path. This is correct (for what I understand). Out of curiosity, why is it not enough to just add the MSR to the ACPI_CPU_DATA? Or is it what you're doing, but OVMF was not restoring MTRRs at S3 resume time either? Paolo