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: Thu, 18 Feb 2016 17:56:08 +0100 From: Radim Krčmář <rkrcmar@...hat.com> To: Paolo Bonzini <pbonzini@...hat.com> Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, Yuki Shibuya <shibuya.yk@...s.nec.co.jp>, Rik van Riel <riel@...hat.com> Subject: Re: [PATCH v2 01/14] KVM: x86: change PIT discard tick policy 2016-02-18 17:13+0100, Paolo Bonzini: > On 17/02/2016 20:14, Radim Krčmář wrote: >> Discard policy uses ack_notifiers to prevent injection of PIT interrupts >> before EOI from the last one. >> >> This patch changes the policy to always try to deliver the interrupt, >> which makes a difference when its vector is in ISR. >> Old implementation would drop the interrupt, but proposed one injects to >> IRR, like real hardware would. > > This seems like what libvirt calls the "merge" policy: Oops, I never looked beyond QEMU after seeing that the naming in libvirt doesn't even match ... I think the policy that KVM implements (which I call discard) is "delay" in libvirt. (https://libvirt.org/formatdomain.html#elementsTime) > > Merge the missed tick(s) into one tick and inject. The guest time > may be delayed, depending on how the OS reacts to the merging of > ticks The "may be delayed" there makes me feel like the timer has to support a guest visible counter of missed ticks. PIT will definitely be delayed if we get another tick while the previous one is still in IRR and there is nothing that the guest can do with it. "catchup" is the other KVM policy and "discard" also needs to allow the guest to handle lost ticks. > where the merged tick is the one placed into IRR. Unlike discard, > "merge" can starve the guest through an interrupt storm. Yeah, starving a VCPU with an interrupt storm is more likely with the changed policy. It's a pretty sad situation if all the time that VCPU gets isn't even enough to run a PIT handler, so I didn't care. The NMI watchdog bug can also be solved without changing the policy. (It's a hack in any case.)
Powered by blists - more mailing lists