From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v5 2/6] x86: allow reading MSR_IA32_TSC with XENPF_resource_op Date: Thu, 22 Jan 2015 14:03:12 +0000 Message-ID: <54C10320.8090107@citrix.com> References: <1421839164-26037-1-git-send-email-chao.p.peng@linux.intel.com> <1421839164-26037-3-git-send-email-chao.p.peng@linux.intel.com> <54C0EAFF0200007800058100@mail.emea.novell.com> <20150122125314.GD28428@pengc-linux.bj.intel.com> <54C10B05020000780005824E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54C10B05020000780005824E@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 , Chao Peng Cc: wei.liu2@citrix.com, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, will.auld@intel.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On 22/01/15 13:36, Jan Beulich wrote: >>>> On 22.01.15 at 13:53, wrote: >> On Thu, Jan 22, 2015 at 11:20:15AM +0000, Jan Beulich wrote: >>>>>> On 21.01.15 at 12:19, wrote: >>>> --- a/xen/arch/x86/platform_hypercall.c >>>> +++ b/xen/arch/x86/platform_hypercall.c >>>> @@ -61,7 +61,7 @@ long cpu_down_helper(void *data); >>>> long core_parking_helper(void *data); >>>> uint32_t get_cur_idle_nums(void); >>>> >>>> -#define RESOURCE_ACCESS_MAX_ENTRIES 2 >>>> +#define RESOURCE_ACCESS_MAX_ENTRIES 3 >>> See my comment on an earlier version. >> The new added MSR_IA32_TSC and existed MSR_IA32_CMT_CTR should be >> read in an atomic unit. How to achieve this if not increase >> MAX_ENTRIES? > These are just two entries nevertheless. The reasons for two in the first place is that it is an indirect MSR read. Upping MAX_ENTRIES to 3 and allowing the operation to get a timestamp as is the only way to synchronously perform the indirect register read and timestamp. Having said this, the only useful timestamp will be at the same point as performing the MSR read. Having a 3rd operation tacked on the end to get a timestamp will be some arbitrary time later, especially if interrupts are enabled. ~Andrew