From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: system freeze when processor.ko is loaded Date: Tue, 12 Apr 2011 18:32:49 +0100 Message-ID: References: <54B2EB610B7F1340BB6A0D4CA04A4F1001008E35D9@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54B2EB610B7F1340BB6A0D4CA04A4F1001008E35D9@orsmsx505.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Wang, Winston L" , Jan Beulich Cc: "Liu, Jinsong" , "xen-devel@lists.xensource.com" , "Jiang, Yunhong" , "Li, Xin" , "Dugger, Donald D" List-Id: xen-devel@lists.xenproject.org On 12/04/2011 18:27, "Wang, Winston L" wrote: >>>>> On 12.04.11 at 00:35, "Wang, Winston L" >> wrote: >>> I think restore only the lower 32bit TSC is good enough, why do we >> need to touch upper 32 bit TSC? >> >> You just can't: A wrmsr to this MSR always updates the full 64-bits, >> just that on some CPUs this update implies the upper 32 bits getting >> zeroed. > You are right, just can't only write lower 32 bit without updating 32 bit > since TSC is always 64 bits:( > So we have to give up the deep C state for those old processors since we still > need to maintain TSC all the time for SMP support. > The solution should go with your patch: re-validate the processor boot with " > X86_FEATURE_TSC_RELIABLE" to see upper 32 bit TSC MSR is writeable at > init_xen_time or not , then decide if allow deep_cstate. This is a better idea > than only allow the processor going to the deep c state with > "x86_FEATURE_CONSTANT_TSC but !X86_FEATURE_NONSTOP_TSC CPUs". > > Would you double test patch before pulling in? we need to check both the old > failed processor and the current one. And what's the power idle power impact. Do you want a chance to Ack the patch before I apply it to xen-unstable? -- Keir >> And even if you could, it wouldn't be easy to deal with the situation >> where the update would carry into the upper 32 bits. >> >> Jan >> >>> 1. I would not think if any processor's deep c-state wakeup from idle >> can >>> more than 100 ms. >>> 2. For 3GHZ processor lower 32bit TSC wrapper around time is ~2.83 >> Sec. >>> 3. The platform timer (22bit ACPI timer) wrapper around is 2.34 sec >> (this is >>> used for counting the delta before enter deep_cstate and before >> wakeup) >>> Just need to change cstate_restore_tsc() and only patch back the >> delta time >>> to the lower 32 bit TSC to make that simple? >>> >>> Winston, >> >> >