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? ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
