From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: xen-4.1: PV domain hanging at startup, jiffies stopped Date: Wed, 31 Aug 2011 23:07:52 +0100 Message-ID: References: <4E5EA3F2.10702@mimuw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E5EA3F2.10702@mimuw.edu.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Marek Marczykowski Cc: Dan Magenheimer , xen-devel@lists.xensource.com, Joanna Rutkowska , Rafal Wojtczuk , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 31/08/2011 22:13, "Marek Marczykowski" wrote: >> They really ought to work out to the same thing. This will trivially be the >> case with tsc_mode=2 because both guest and hypervisor will see the same >> (real) values from RDTSC, and use the same offsets and sacle factors to turn >> that into a current system time. When using emulated TSC in the guest >> (tsc_mode=0,1) then the TSC values it sees, and the offsets and scale >> factors it applies, are different. It is intended that it should result in >> the same values being computed for NOW(), but I suppose something could be >> going wrong there. > > NOW() calls get_s_time() which doesn't look to be depended on tsc_mode > setting. Have I missed something? I mean the result of xen_clocksource_read() in the guest kernel, which we expect to match the result of executing NOW() in the hypervisor. The former does depend on tsc_mode because xen_clocksource_read() uses RDTSC. -- Keir