On Wed, May 05, 2010 at 10:33:52AM -1000, Zachary Amsden wrote: > On 05/05/2010 09:19 AM, Glauber Costa wrote: > >Currently, in the linux kernel, we reset kvmclock if we are rebooting > >into a crash kernel through kexec. The rationale, is that a new kernel > >won't follow the same memory addresses, and the memory where kvmclock is > >located in the first kernel, will be something else in the second one. > > > >We don't do it in normal reboots, because the second kernel ends up > >registering kvmclock again, which has the effect of turning off the > >first instance. > > > >This is, however, totally wrong. This assumes we're booting into > >a kernel that also has kvmclock enabled. If by some reason we reboot > >into something that doesn't do kvmclock including but not limited to: > > * rebooting into an older kernel without kvmclock support, > > * rebooting with no-kvmclock, > > * rebootint into another O.S, > > > >we'll simply have the hypervisor writting into a random memory position > >into the guest. Neat, uh? > > > >Moreover, I believe the fix belongs in qemu, since it is the entity > >more prepared to detect all kinds of reboots (by means of a cpu_reset), > >not to mention the presence of misbehaving guests, that can forget > >to turn kvmclock off. > > > >It is also necessary to reset other msrs, so this patch resets > >everything that kvm exports through its MSR list. > > Does that include the TSC? AFAIK, yes. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
