On Wed, Dec 10, 2008 at 12:19:28PM +0200, Avi Kivity wrote: > Marcelo Tosatti wrote: >> VMX initializes the TSC offset for each vcpu at different times, and >> also reinitializes it for vcpus other than 0 on APIC SIPI message. >> >> This bug causes the TSC's to appear unsynchronized in the guest, even if >> the host is good. >> >> Older Linux kernels don't handle the situation very well, so >> gettimeofday is likely to go backwards in time: >> >> http://www.mail-archive.com/[email protected]/msg02955.html >> http://sourceforge.net/tracker/index.php?func=detail&aid=2025534&group_id=180599&atid=893831 >> >> Fix it by initializating the offset of each vcpu relative to vm creation >> time, and moving it from vmx_vcpu_reset to vmx_vcpu_setup, out of the >> APIC MP init path. >> > > This looks fine, but have you tested it on a host with unsync tsc? I'm > worried that we'll get regressions there even on uniprocessor guest. > I'd like to keep the current behaviour for the special case of > uniprocessor guest on unsync tsc host.
I don't see how. For UP guests the TSC is initialized to zero during vcpu setup, similarly to the current behaviour. Can you explain? > There's a further improvement possible: treating the tsc as shared among > all vcpus, so that a guest write to one will update all of them, like on > a hyperthreaded core. This will prevent the unsyncing caused by the > host trying to sync tscs, and the vcpu being scheduled away at the same > time. You mean the guest trying to sync tscs? Indeed, that is sensitive to scheduling (like most of the calibration algorithms that are time sensitive). Your suggestion differs from the behaviour of actual hardware, though. Anyway, this patch is trivial, and an improvement compared to the current situation. What are the possible implications of simply not zeroing the guest TSC ? Guests will have access to the hosts TSC value, but how bad that is? -- 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
