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
| ||
|
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/
Powered by blists - more mailing lists