WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: 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 17:48:26 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "winston.l.wang" <winston.l.wang@xxxxxxxxx>
Delivery-date: Thu, 14 Apr 2011 09:49: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=PCkH0sabB8+VwnVspS8LlTgX2JC/WSMsn3ehsBiVT5w=; b=JPT78sYhvkwMqc71Omc/ZllDuvKYlP7EmTzmjYIlFseBSkKMKyQXzYTcUVL2SmUUDJ PGDyqN+SmdfcsGfof2AzLIHOqxm5VuCVsIj5b4+CIFtXj58WkCnp/2fMaBwCbe9KTjrf +tzv45DyEhixzVfIhVxWJB9Wq7JDAWFTajz/c=
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=qdfPvUx4q/vhddzz+nFLNuwoPmEZJaXL9pHWvF0OhMx84TGHIuP51J9nPI06z/l1Eb 1OURsSG7ujelWGbyq5rKjW+T/b9a2nWRjR3GAnl6is4b0utdSwkJgCT6TJy7xpUuKoLD asb1zhQDOzQQWoYqLjw+Lu90O9nlaxSyST79s=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DA73CBD020000780003BBB0@xxxxxxxxxxxxxxxxxx>
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: Acv6w8Yj5TbRjJlU30K3KA5QViPHLQ==
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/12.28.0.101117
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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