Re: [RFC] fix VMX TSC synchronicity

[Marcelo Tosatti <marcelo-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>]

On Wed, Jan 16, 2008 at 02:54:15PM +0100, Andi Kleen wrote:
> 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.

Forcing clustered APIC mode works only on SMP, and there were high CPU
consumption on Windows SMP guests due to C3 state being reported (fixed
in kvm-30 something).

So perhaps:
- Faking clustered APIC on SMP 
- Faking C3 on UP

And turning of the TSC bit (for 32-bit guests).

Is the way to go? 

Avi, do you understand why C3 was causing the Windows SMP problems ?

/* Common C-state entry for C2, C3, .. */
static void acpi_cstate_enter(struct acpi_processor_cx *cstate)
{
        if (cstate->space_id == ACPI_CSTATE_FFH) {
                /* Call into architectural FFH based C-state */
                acpi_processor_ffh_cstate_enter(cstate);
        } else {
                int unused;
                /* IO port based C-state */
                inb(cstate->address);
                /* Dummy wait op - must do something useless after P_LVL2 read
                   because chipsets cannot guarantee that STPCLK# signal
                   gets asserted in time to freeze execution properly. */
                unused = inl(acpi_gbl_FADT.xpm_timer_block.address);
        }
}

Clearly that inb() won't actually idle under QEMU. So the question is,
if C3 stated is reported, that port read should be emulated... But how? 

http://www.mail-archive.com/kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org/msg05360.html

Zhao, Yunfeng wrote:
>> I ran the same image under qemu 0.9.0, uniprocessor, and got the same
>> results: high host cpu usage while the guest is idle.  Most likely the
>> BIOS ACPI tables are misconfigured and the Windows idle loop is
>>     
> confused.




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/