On Wed, Jun 16, 2010 at 05:13:02PM +0300, Avi Kivity wrote: > On 06/16/2010 04:58 PM, Glauber Costa wrote: > >On Wed, Jun 16, 2010 at 04:11:26PM +0800, Jason Wang wrote: > >>Zachary Amsden wrote: > >>>Kernel time, which advances in discrete steps may progress much slower > >>>than TSC. As a result, when kvmclock is adjusted to a new base, the > >>>apparent time to the guest, which runs at a much higher, nsec scaled > >>>rate based on the current TSC, may have already been observed to have > >>>a larger value (kernel_ns + scaled tsc) than the value to which we are > >>>setting it (kernel_ns + 0). > >>> > >>This is one issue of kvmclock which tries to supply a clocksource whose > >>precision may even higher than host. > >What if we export to the guest the current clock resolution, and when doing guest > >reads, simply chop whatever value we got to the lowest acceptable value? > > The clock resolution can change, and while we can expose it reliably > through pvclock, do we need a notification so that the guest can > update other internal structures? I believe the only thing we need is to warn the guest whenever this changes. We can probably fit it in one of the paddings we have, and add a flag to say it is valid (now that we have the infrastructure). -- 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
