linux-kernel - Re: [KVM timekeeping 10/35] Fix deep C-state TSC desynchronization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C8F52C2.1020606@redhat.com>
Date:	Tue, 14 Sep 2010 12:47:30 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Jan Kiszka <jan.kiszka@...mens.com>
CC:	Zachary Amsden <zamsden@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Glauber Costa <glommer@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <johnstul@...ibm.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [KVM timekeeping 10/35] Fix deep C-state TSC desynchronization

  On 09/14/2010 12:40 PM, Jan Kiszka wrote:
> >>  For yet unknown reason, this commit breaks Linux guests here if they are
> >>  started with only a single VCPU. They hang during boot, obviously no
> >>  longer receiving interrupts.
> >>
> >>  I'm using kvm-kmod against a 2.6.34 host kernel, so this may be a side
> >>  effect of the wrapping, though I cannot imagine how.
> >>
> >>  Anyone any ideas?
> >>
> >>
> >
> >  Most likely, time went backwards, and some 'future - past' calculation
> >  resulted in a negative sleep value which was then interpreted as
> >  unsigned and resulted in a 2342525634 year sleep.
>
> Looks like that's the case on first glance at the apic state.

Aside from this bug, it would be better for the guest to use signed 
arithmetic (or check beforehand) and not sleep if the future is already 
past.

> >
> >  Does your guest use kvmclock, tsc, or some other time source?
>
> A kernel that has kvmclock support even hangs in SMP mode.

Does it have the recent kvmclock patches backported? (should be in 
latest -stable).

> The others
> pick hpet or acpi_pm. TSC is considered unstable.
>
>

Wierd.  But perhaps it's the scheduler clock that's misbehaving, IIRC it 
has its own local clock.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/