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.
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.
--
error compiling committee.c: too many arguments to function
--
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
