On Wed, 19 Jun 2013 15:29:31 +0200 Paolo Bonzini <pbonz...@redhat.com> wrote:
> Il 19/06/2013 15:20, Batalov Eugene ha scritto: > > > > I've missed this detail. It looks like Igor's patch doesn't bring > > secondary cpus kvm_clocksource behavior back to one before the regression, > > Before the regression per_cpu variables are used to allocate > > kvm_pv_clock areas. > > To to usage of percpu variables bootstrap cpu kvm_clock area contents > > were copied to smp secondary cpus kvm_clock areas when they were started. > > Bootstrap cpu kvm_clock area was not zeroed at this time. > > So kvm_pv_clock for secondary cpus never returned "zero" clock before > > the regression. > > > > During the analysis of the bug I introduced idea to return zero before > > kvm clocksource is initialized for secondary cpus > > just like bootstrap cpu does on kernel boot. You can read that in BZ. > > Yes, this is why I prefer to invert the two function calls. But Igor's > patch fixes the hang (trivially because version is even) and is more > appropriate for -rc6. I'll post this swap shortly, but zeroing out hv_clock at init time, would be still needed to provide sane values there if ftrace enabled at that time. > > Paolo > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
