guest needs to boot with clock=acpi_pm (older AMD freq scaling issues)

I'm concerned about the possible side-effects of this change, so have not accepted the kvm upload yet from the queue. I think there needs to be further evidence of why this fix is safe, or else defer to SRU; changed the milestone accordingly.

Try adding no-kvmclock to the guest kernel command line. If that addresses the problem, I'd suggest removing CONFIG_KVM_CLOCK from the guest kernel. There have been some lurking problems with kvm clock.

I've been hitting this one as well. I usually add clocksource=acpi_pm to solve it. I'll try no-kvmclock and report success/failure.

I had problems until i disabled cpufreq on the host. kvm has problems with that

The issue is that some amd platforms (pre-Barcelona) are not able to have guests that use the tsc as a clock source.

Either:
 a) Hosts with these processors should disable cpu frequency scaling, or
 b) Guests should use clock=acpi_pm

We could add a check to the kvm or qemu binary to check if cpu frequency scaling is enabled and throw an error. Even this is imperfect, though, as you could still screw yourself if you enable it after the vm starts.

I'm forward this upstream to see what they think.

:-Dustin

Okay, so thinking about this so more, here's how I propose solving this...

 * Modify the kvm init script to check if your CPU is a buggy (cat /proc/cpuinfo, AMD processor, cpu family < 16), then cpu-frequency scaling should be turned off

:-Dustin

\o/ cpu family : 15
FYI running with no-kvmclock (as suggested by Anthony in comment 2) also seems to work around the issue.

Dustin: running guests with clocksource=acpi_pm is also a valid solution for those who don't want to throw out freqscaling completely (I am one of those), so I suggest the init script check (if it is blocking and not just a warning) could be optionally disabled by a YES_I_KNOW_I_NEED_TO_ADD_CLOCKSOURCE_ACPI_PM="yes" /etc/default/kvm setting ?

Thierry-

Yes, I agree (as I'm the owner of 4+ effected AMD cpu's on which I
don't want to lose frequency scaling)...

:-Dustin

If no-kvmclock helps, it's possible to disable this in the host kernel.

On Tue, Jun 23, 2009 at 7:30 PM, Anthony Liguori<email address hidden> wrote:
> If no-kvmclock helps, it's possible to disable this in the host kernel.

Anthony-

What's the downside of no-kvmclock, if we decided to make this a
default in the Ubuntu server kernel?

:-Dustin

Dustin Kirkland wrote:
> On Tue, Jun 23, 2009 at 7:30 PM, Anthony Liguori<email address hidden> wrote:
>
>> If no-kvmclock helps, it's possible to disable this in the host kernel.
>>
>
> Anthony-
>
> What's the downside of no-kvmclock, if we decided to make this a
> default in the Ubuntu server kernel?
>
> :-Dustin
>

Assuming it worked? Potentially greater time drift in the guest.

Regards,

Anthony Liguori

http://patchwork.kernel.org/patch/19007/

On Wed, Jun 24, 2009 at 10:38 AM, Anthony Liguori<email address hidden> wrote:
> Assuming it worked?  Potentially greater time drift in the guest.

Can that be helped with NTP in the guest?

:-Dustin

Can anyone reproduce this problem in karmic's qemu-kvm-0.11? Marking incomplete. Please confirm if you still experience this issue there.

I'm marking won't fix against Jaunty. I don't think this rises to SRU, since there are multiple workarounds.

:-Dustin

Thierry, Daniel, can you reproduce this?

:-Dustin

My recent karmic ISO testings (using default kernel parameters) didn't hang... I'll disable no-kvmclock in my guests and let you know if I can reproduce it with current qemu-kvm.

AFAICT it's all good now.

Thanks, Daniel.

Thierry, I'm marking 'fix released'. Please reopen with 'confirmed', if you can reproduce this on the latest Karmic qemu-kvm.

:-Dustin

I am marking this as 'confirmed' as I can reproduce the problem with the latest qemu-kvm package. Turning off cpu frequency scaling is a valid workaround for me, but the clock on the guests drift a lot whenever I forget to change the governor.

$ LANG=C apt-cache policy qemu-kvm
qemu-kvm:
  Installed: 0.11.0-0ubuntu6.3
  Candidate: 0.11.0-0ubuntu6.3
  Version table:
 *** 0.11.0-0ubuntu6.3 0
        500 http://archive.ubuntu.com karmic-updates/main Packages
        100 /var/lib/dpkg/status
     0.11.0-0ubuntu6 0
        500 http://archive.ubuntu.com karmic/main Packages

I'm unassigning myself this bug, as I haven't found the time to fix it, and I personally haven't hit this bug in a very long time. Leaving the bug open, and I would be happy to review/sponsor/upload a fix if someone else submits a patch.

Daniel-

You opened this bug... Have you experienced this problem on Lucid (or Karmic) or any time recently?

Thierry-

You originally confirmed it. Can you confirm it again against Lucid?

Sorry, read a bit further down and I see that both Thierry and Daniel are reporting Success with recent Ubuntu. Closing for now. Please reopen if this is still an issue. Thanks!

Hallo Dustin,

i reported this bug too for Hardy. Its gone with karmic.

Reagrds, Kurt

Am 02.03.2010 00:36, schrieb Dustin Kirkland:
> Daniel-
>
> You opened this bug... Have you experienced this problem on Lucid (or
> Karmic) or any time recently?
>
> Thierry-
>
> You originally confirmed it. Can you confirm it again against Lucid?
>
>

--
Kurt Harders
PiN GmbH
Leimbacher Str. 36
42281 Wuppertal

T +49 202 2 50 11 64
F +49 202 2 50 11 65
M +49 171 8 36 82 33

Geschäftsführer:
Kurt Harders und Andre Dressler

Eingetragen beim AG Wuppertal
HRB 9102
USt.ID DE 186029298