This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs u

To: "Wang, Winston L" <winston.l.wang@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Thu, 14 Apr 2011 22:06:13 +0100
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, KeirFraser <keir@xxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>
Delivery-date: Thu, 14 Apr 2011 14:07:17 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=Uc2XG5ZA+rQVi3C9WcGMjLT3l4ab2NzKRamja3fJYH4=; b=n7pv9M4zBoRBx+5cdTDXr3ZhCvLqAjPQUsXhIL5oTonph1OurIEs97t3Z/U8JOenqH uWJWggGWZfaIgeEIPS4tHA3w9/F/LpQ2O4M07Xg8s4GxvRnc0SPZ2G+TjMf8oQFHDE1G wWUxweDP0+0GtXuecLqj01XlblbyYqorXb2z8=
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=FmluNPMkqUhtkr2US32ssjgoTlYp+FSbhgawqU13kh7cpbtEWhy/C0y5jp1FA0CVSl eCTmtNdCIm/arNHcrLpXQRKLprzNPPN8a+RoyUzk5ETsq2lYpMQWIQwImRPuLLzHmzu0 NOEVS4zzXCf0zgf9m3R5aKfhJUCKd0KJA9QSM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <54B2EB610B7F1340BB6A0D4CA04A4F100100CBC5C9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acv6w8Yj5TbRjJlU30K3KA5QViPHLQABlgqQAAdqubg=
Thread-topic: [Xen-devel] [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits
User-agent: Microsoft-Entourage/
On 14/04/2011 19:33, "Wang, Winston L" <winston.l.wang@xxxxxxxxx> wrote:

> Jan and Keir,
> Great efforts for turning the test code re-validate the processor with
> (X86_FEATURE_TSC_RELIABLE) set. We know for sure that the broken old
> processors any write TSC will Zero the upper 32 bit. So can we move this test
> code as early as possible, say immediately after the early Processor init code
> where checking CPU id and set X86_FEATURE_TSC_RELIABLE?

For our meaning of TSC_RELIABLE, there's no need for its setting to rely on
TSC 64-bit writability. I think leaving it where it is in init_xen_time() is
probably fine.

 -- Keir

> Thanks,
> Winston,
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
>> Sent: Thursday, April 14, 2011 9:48 AM
>> To: Jan Beulich
>> On 14/04/2011 17:28, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>> I also simplified the actual writability check itself. I couldn't
>> figure out
>>>> what the benefit of your more complex approach would be. In fact it
>> looked
>>>> like it wouldn't work if bit 32 was set already in the TSC counter,
>> as then
>>>> you would write back an unmodified TSC (and in fact you would detect
>> the
>>>> wrong way round, as you'd see a big delta if the write silently
>> cleared bit
>>>> 32 (and bits 33-63)). And the final write of tsc+4*delta, wasn't
>> sure what
>>>> that was about either! But if you can explain why your test is
>> better I'd be
>>>> happy to use it as you originally wrote it.
>>> So you were concerned about getting the TSC slightly off, and now
>>> you flush it to zero, without any attempt to restore the original
>>> value?
>> Haha, well it doesn't matter too much if we sync TSCs as we bring them
>> online anyway. But I agree it makes sense to try if we are only able to
>> write the lower 32 bits -- we can at least hope the write test happens
>> while
>> TSC counter is a 32-bit value anyway, and at least we've had a best-
>> effort
>> attempt to keep TSCs in sync.
>>> As to my original test being broken - I don't think that was the case:
>>> The first write used (u32)tsc as the input, so the two writes, if
>>> happening completely, would be certain to be apart by
>>> approximately 1<<32 (or more, depending on what was in the
>>> upper half originally).
>> Ah yes, I missed the importance of the (u32)tsc write. Fair enough,
>> your way
>> is better. :-)
>>> The only case not handled was if the TSC
>>> overflowed 64 bits during the process - I considered this case
>>> hypothetical only.
>>> The final write of tsc+4*delta was basically an attempt to restore
>>> the value that would have been there if we didn't fiddle with it.
>> But the write is actually tsc + 4*(s32)(tmp-tsc), and tmp has 1U<<32
>> ORed
>> into it (because it was read after your second write to the TSC.
>> Perhaps we
>> should just write back the full original tsc and call that good enough?
>>  -- Keir
>>> The factor 4 was sort of invented, on the basis that the delta was
>>> between one write and an immediate read back, with there being
>>> a total of four such windows (read->write or write->read). As
>>> one wouldn't get it precise anyway, the number seemed fine to
>>> me, though just writing back the original values probably wouldn't
>>> have been much worse.
>>> Jan

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>