[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Thu, 14 Apr 2011 10:18:18 +0100
  • Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "winston.l.wang" <winston.l.wang@xxxxxxxxx>
  • Delivery-date: Thu, 14 Apr 2011 02:19:20 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=hF1fR6vRm04kbpwbBq3XiRbwptB7cth0WtNsvqKnl6Y/R61+NJyaGlX8c+6q8koLom TC2BtFJCpqCtCjcd0g9PxrR0L5JJ43tT0h7Zctp8SjT64+KnyVuRttfKyKVYQfBicM1I eu6ZHeC3RRND1qAsPUvJN6kiap9D1rgjH5s+I=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acv6hOQeze0VqJS2I02yvYEvMmueUQ==
  • Thread-topic: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits

On 14/04/2011 09:06, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> For physically-added CPUs only. Kind of unavoidable, that one: we can only
>> try to do our best in that case. And let's face it, that probably affects
>> exactly zero production users of Xen/x86 right now.
> 
> That latter part I agree to.
> 
> But what are you afraid of? Probing the TSC write shouldn't do any
> harm.

You will end up with a BSP TSC value different than what it would have been
if you had not probed. Since you write back a (slightly) stale TSC value.
Which would increase cross-CPU TSC skew if the platform has done a good sync
job at power-on.

Now, do I personally think this much matters? Not really, since I believe
that direct guest TSC access is a huge non-issue. But it is something that
Dan disagreed on, he did a bunch of work on time management, and the code
as-is does try quite hard to avoid writing TSC if at all possible. I don't
think it's a good idea to change this without feedback from Dan, at least.

> Additionally, did you read the comment immediately preceding
> the probing code? AMD doesn't guarantee the TSC to be writable at
> all.
> 
>>> cstate_restore_tsc() also has no such gating afaics.
>> 
>> It is gated on NONSTOP_TSC which is implied by TSC_RELIABLE.
> 
> Ah, yes. But (I think) not architecturally, only by virtue of how
> code is currently structured. If that changes, we'd be back at a
> latent (and quite non-obvious) bug.

Yeah, if we want to continue to try avoiding write_tsc() on TSC_RELIABLE
then we should assert !TSC_RELIABLE on the write_tsc() path in
cstate_tsc_restore().

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.