>>> On 14.04.11 at 18:05, Keir Fraser <keir@xxxxxxx> wrote:
> On 14/04/2011 08:18, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>> This means suppressing the uses in time_calibration_tsc_rendezvous(),
>> cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot
>> hang of Linux Dom0 when loading processor.ko on such systems that
>> have support for C states above C1.
>
> I've attached a version which would avoid doing the writability test on
> TSC_RELIABLE systems. See what you think.
Looks reasonable.
> 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?
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). 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.
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
|
Home