Re: [RFC] fix VMX TSC synchronicity

Andi Kleen
2008-01-16T13:54:15Z

On Wed, Jan 16, 2008 at 03:38:45PM +0200, Avi Kivity wrote:
> Andi Kleen wrote:
> >Linux checks a couple of things: e.g. if there are no deep C states
> >and if there are no clustered nodes in the APIC etc.
> >
> >It might be reasonable to check the clock source of the kernel
> >and if it's not TSC force one of these in the emulated firmware
> >environment
> >
> >
>
> The problems are with older guests which assume the tsc is okay. Newer
> guests check the tsc and conclude that it isn't usable.

If the guest would get it wrong running natively on the host
I guess it would be reasonable to require an option that forces
TSC off. Disabling the TSC bit unfortunately won't work for 64bit
guests, but for probably most 32bit guests.

But for non broken guests they can only do that if the guest has the same
visibility into the firmware state as the host. For the easy cases Linux will
check it anyways becaused on standard the TSC synchronicity check, but
there are cases where the TSCs only drift apart slowly over a longer time

[I finally fixed the clocksource watchdog now to catch this case, but
it will be only in .25]

I think it would be better to fake at least some of the usual
firmware cues for bad TSC if the host does not use it.

>
> >>You might taskset guests into a single node on such systems, which is a
> >>good idea anyway.
> >>
> >
> >Ah pushing the problem to the user. An easy, but typically wrong, solution.
> >
>
> If you have other suggestions I'll be happy to hear them. I don't like
> this either.

Check if host is using TSC source and if not force a clustered
APIC mode (only works for 64bit unfortunately) or fake a C3 state
in ACPI and on AMD clear the synchronous TSC bit.

-Andi