On 04/21/2010 03:05 AM, Zachary Amsden wrote:
On 04/19/2010 11:39 PM, Avi Kivity wrote:
On 04/19/2010 09:35 PM, Zachary Amsden wrote:
Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?
Not sure, IIRC we clear that when the TSC sync test fails, eg when we
mark the tsc clocksource unusable.
Worrying. By the time we detect this the guest may already have
gotten confused by clocks going backwards.
Upstream, we are marking the TSC unstable preemptively when hardware
which will eventually sync test is detected, so this should be fine.
ENOPARSE?
Instead of detecting TSC warp, c1e_idle, power_saving_mwait_init,
tsc_check_state, dmi_mark_tsc_unstable all do something similar to
this to disable TSC before warp even occurs:
static void c1e_idle(void)
{
if (need_resched())
return;
if (!c1e_detected) {
u32 lo, hi;
rdmsr(MSR_K8_INT_PENDING_MSG, lo, hi);
if (lo & K8_INTP_C1E_ACTIVE_MASK) {
c1e_detected = 1;
if (!boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
mark_tsc_unstable("TSC halt in AMD C1E");
printk(KERN_INFO "System has AMD C1E enabled\n");
set_cpu_cap(&boot_cpu_data, X86_FEATURE_AMDC1E);
}
}
That works within a socket; but multiple socket machines need not feed
all sockets from the same crystal and reset line (esp. likely for
multiple board machines, but might even happen with single board
FSB-less processors).
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
