On 11/07/2011 04:59 PM, Peter Zijlstra wrote: > > > > + */ > > > > + if (!kvm_is_in_guest()) > > > > + irq_work_queue(&pmc->vcpu->arch.pmu.irq_work); > > > > + else > > > > + kvm_make_request(KVM_REQ_PMI, pmc->vcpu); > > > > + } > > > > +} > > > > > > I'm not sure I get this, since the counters are vcpu task bound and only > > > count while the guest is running as per (144d31e6f19) how can we get an > > > NMI outside of guest context with the vcpu not halted? > > > > PMI skew. Do we know how bad it can get? > > You're talking about the PMI getting asserted before leaving guest mode > but not getting ran until after we left guest mode? Yes (here, "guest mode" is not the hardware guest mode, but what kvm_is_in_guest() returns). > But in that case we know the guest is stopped, right? So we can simply > set that REQ_PMI bit and have guest entry sort things, no? Unless there is no guest entry, due to the guest sleeping. Consider the sequence: guest: nop hardware: counter overflow; PMI sent to APIC guest: hlt hardware: begin vmexit due to HLT host: process vmexit mark as outside guest mode (i.e. kvm_is_in_guest() now returns false) schedule(), since the guest is sleeping (and assume no interrupts pending) hardware: APIC finally posts NMI host: process NMI; set KVM_REQ_PMI iret host: happily do other things, ignoring that we need to post a PMI to the guest note, this needs a fairly huge PMI skew to happen. (btw, like userspace, kvm PMIs may as well be ordinary interrupts. Should we consider some logic to only make them NMIs if some counter requires it? NMI costs are set to increase dramatically with the check-all-possible-sources patchset). -- error compiling committee.c: too many arguments to function -- 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
