From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: write_tsc in a PV domain? Date: Wed, 26 Aug 2009 15:30:33 -0700 Message-ID: <4A95B789.6020604@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: "Xen-Devel (E-mail)" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 08/26/09 13:23, Dan Magenheimer wrote: >> You can think of it this way: a Xen PV VCPU has no tsc. There is a >> register that can be read with "rdtsc", but that're purely >> part of Xen's >> time ABI and is not independently useful. The ABI includes >> no notion of >> writing to that register. Usermode code can execute "rdtsc", but >> without access to the rest of the time parameters it just returns some >> undefined bits with no relationship to time. >> > While I think I understand entirely why you would want to > think of it that way, there's thousands (millions?) of applications > out there that would beg to differ. They DO assume that > rdtsc bears "some" relationship to time. They are wrong. Linux doesn't offer the tsc to usermode for its use. The closest it gets is vgettimeofday, which we could implement better. > Indeed Linux itself > does. A pv linux guest doesn't have a TSC in the same way that it doesn't have a TSS or any number of other CPU features. It would be a grave error for the kernel to use a tsc-based clocksource rather than the Xen pv clocksource. A Xen PV VCPU bears a passing resemblance to an Intel x86 CPU, but should not be confused with one. > Exactly what that relationship to time is defined to be is > open to debate, and whether Xen supports whatever relationship > is defined is also debatable (especially in the presence of > migration). But defining rdtsc as returning random bits > is not an acceptable solution for Xen. Dom0 won't even > boot if rdtsc returns random bits so Xen must already be > guaranteeing that rdtsc has "some" relationship to time. > No, it really doesn't. It provides a PV clock, which includes "rdtsc" as part of its ABI. It is not a general tsc. You can't meaningfully execute "rdtsc" without also being (indirectly) aware of what pcpu its running on and applying the appropriate corrections to turn it into system monotonic time. Executing rdtsc willy-nilly gets you useless results; fortunately no PV Xen kernel does that. > We've been lucky so far with allowing rdtsc to execute directly > in hardware, but we really do need to fix it properly. No, that's false. The current Xen time model works fine for all guests using it correctly. Emulating rdtsc for hvm guests is another question entirely. > But since applications cannot WRITE to tsc and Xen has some > control over the OS->Xen PV API, it might be safe to define that > write_tsc is a no-op. > No, write_tsc is meaningless, and anyone trying to execute it is not even wrong. J