On Mon, Nov 07, 2011 at 05:22:21PM +0100, Peter Zijlstra wrote: > On Mon, 2011-11-07 at 17:25 +0200, Avi Kivity wrote: > > On 11/07/2011 05:19 PM, Gleb Natapov wrote: > > > > > > > > note, this needs a fairly huge PMI skew to happen. > > > > > > > No, it need not. It is enough to get exit reason as hlt instead of nmi > > > for a vcpu to go to blocking state instead of reentering guest mode. > > > Note that we do not check request flags in kvm_arch_vcpu_runnable(). > > > > Right. > > > > If we had a guarantee about the maximum skew, we could add a check for > > KVM_REQ_PMI in kvm_vcpu_block(). > > Right, it shouldn't be more than a few instructions since its NMIs we're > talking about, but I'm not sure there's any really hard guarantees on, > hardware folks would be able to say more. > > Typically you can assert NMIs at instruction boundaries, but things like > instruction fusing and a few 'special' insn can delay NMI delivery. then > again, I'm clueless as to the actual implementation details of any of > this stuff. > > Also I'm not sure if there's any non-deterministic delays in the PMU > event -> PMU overflow -> PMI raise path that could push you out into > silly land. > > So yeah, I think the proposed code is fine, although I think the comment > can be improved by mentioning the vcpu hlt case. > Will do. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
