Re: [PATCH 0/4] paravirt clock patches

Glauber Costa
2008-05-09T13:25:15Z

Marcelo Tosatti wrote:
> On Wed, May 07, 2008 at 08:45:12PM +0200, Gerd Hoffmann wrote:
>> Ok folks, here is the band aid fix for testing from the odd bugs
>> department. Goes on top of the four patches of this series. A real,
>> clean solution is TBD. Tomorrow I hope (some urgent private problems
>> are in the queue too ...).
>>
>> Problem is the per-cpu area for cpu 0 has two locations in memory, one
>> before and one after pda initialization. kvmclock registers the first
>> due to being initialized quite early, and the paravirt clock for cpu 0
>> stops seeing updates once the pda setup is done. Which makes the TSC
>> effectively the base for timekeeping (instead of using the TSC for
>> millisecond delta adjustments only). Secondary CPUs work as intended.
>>
>> This obviously screws up timekeeping on SMP guests, especially on hosts
>> with unstable TSC.
>>
>> happy testing,
>
> Gerd,
>
> SMP guests can boot and seem stable. Thanks!
>

There are also other cases that suffer from the same problem: living
in a per-cpu area before setup_per_cpu_area is done, and thus, having to
update the addresses later on. arch/x86/kernel/setup.c has an example of
such code, the apicid mappings.

With one more user of it arriving, as a result of something that turned
out to be a hard to find issue, I'm starting to get the feeling that we
can do better than this, on the overall.

Looking quickly at the code, it seems to me that moving the per-cpu
initialization earlier is not possible, or at least, not trivially possible.
So maybe declare the per-cpu areas in a special section, then in
setup_per_cpu_areas, copy them into the definitive per-cpu section and
update the callers?

What do you think?