Marcelo Tosatti <[email protected]> writes: >> Yes, it was an another option to fix this. As note, the wrong percpu >> usage (use it before initialization) is still true even if merged >> KVM_CLOCK. > > Its fine, i believe, because there is a percpu area for the "boot > processor" (see __per_cpu_offset at arch/x86/kernel/setup_percpu.c) > before proper initialization.
Yes. I thought to use early_per_cpu() or similar though, finally I decided to make a patch with minimum logic change. > Can you please confirm the proposed config merge fixes the problem > for you? kvm-clock: Using msrs 4b564d01 and 4b564d00 kvm-clock: cpu 0, msr 0:1e80f01, boot clock ... kvm-clock: cpu 0, msr 0:3e3d2f01, primary cpu clock ... kvm-clock: cpu 1, msr 0:3e5d2f01, secondary cpu clock I confirmed kvm-clock of boot-cpu switched address properly with your patch (msr xxx:yyy is gpa). This fix the problem. - hypervisor. + hypervisor. It includes a paravirtualized clock, so that instead BTW, in the patch, above line is having the trailing space - "instead ". + of relying on a PIT (or probably other) emulation by the + underlying device model, the host provides the guest with + timing infrastructure such as time of day, and system time Thanks. -- OGAWA Hirofumi <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
