From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v17 00/23] x86/PMU: Xen PMU PV(H) support Date: Tue, 20 Jan 2015 11:38:38 -0500 Message-ID: <54BE848E.9010809@oracle.com> References: <1420494257-12877-1-git-send-email-boris.ostrovsky@oracle.com> <54BE3E150200007800056E5F@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54BE3E150200007800056E5F@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: kevin.tian@intel.com, suravee.suthikulpanit@amd.com, tim@xen.org, dietmar.hahn@ts.fujitsu.com, xen-devel@lists.xen.org, Aravind.Gopalakrishnan@amd.com, jun.nakajima@intel.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On 01/20/2015 05:37 AM, Jan Beulich wrote: >>>> On 05.01.15 at 22:43, wrote: >> Changes in v17: >> * Disable VPMU when unknown CPU vendor is detected (patch #2) >> * Remove unnecessary vendor tests in vendor-specific init routines (patch #14) >> * Remember first CPU that starts mode change and use it to stop the cycle (patch #13) >> * If vpmu ops is not present, return 0 as value for VPMU MSR read (as opposed to >> returning an error as was the case in previous patch.) (patch #18) > Any particular reason for this? PVH guests access MSR_IA32_MISC_ENABLE early during boot, before VPMU initialization code had a chance to run and set vpmu ops. Returning 1 from vpmu_do_msr() would result in a fatal fault. (This change would also be consistent with what core2_no_vpmu_ops does.) I should have explained this in the cover letter. -boris