linux-kernel - Re: [KVM timekeeping 26/35] Catchup slower TSC to guest rate

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] [day] [month] [year] [list]

Message-ID: <4C86B948.9050000@redhat.com>
Date:	Tue, 07 Sep 2010 12:14:32 -1000
From:	Zachary Amsden <zamsden@...hat.com>
To:	"Dong, Eddie" <eddie.dong@...el.com>
CC:	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	Avi Kivity <avi@...hat.com>,
	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 26/35] Catchup slower TSC to guest rate

On 09/06/2010 05:44 PM, Dong, Eddie wrote:
> Zachary:
> 	Will you extend the logic to cover the situation when the guest runs at higher than the guest rate but the PCPU is over committed. In that case, likely we can use the time spent when the VCPU is scheduled out to catch up as well. Of course if the VCPU scheduled out time is not enough to compensate the cycles caused by fast host TSC (exceeding a threahold), we will eventually have to fall back to trap and emulation mode.
>   

It is possible to do this, but it is rather dangerous. We can't let the
guest clock accelerate without bounds. We could put a limit on the
maximum overrun the TSC is allowed to reach, and then switch into
trapping mode, but this pre-supposes we will actually get an interrupt
in time. A CPU heavy guest with little host activity could easily
overrun much further than we would like unless we have a way to reliably
trigger interrupts near the time of maximum allowed overrun.

So, first, we must have a way to get such interrupts; this is needed
anyway, for the catchup case, we have a similar problem with underrun
which must be addressed. It's quite possible to add the mode you
describe once that feature is in, but it also adds even more complexity
to an already intricate clock system (which is one of the problem with
the latter part of this patch series).

Second, this mode of operation is incompatible with SMP guests under all
circumstances. SMP guests with mismatched clock speeds must always run
in trapping mode, as it is not possible to synchronize the catchup /
trap switching without extremely heavyweight measures (use IPI wakeup).
Those mechanisms will not only cost more than the trapping overhead
(future, faster systems, and larger, more parallel systems), but they
will also damage host performance (unneeded wakeups when other VCPUs are
not scheduled). Unless, of course, we gang-schedule... but that is a
difficult change and a very different mode of operation. Getting rid of
TSC trap overhead on systems with non-constant TSC isn't a sufficient
motivation for that kind of design change.

Zach
--
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/