On Mon, Nov 07, 2011 at 05:13:17PM +0200, Avi Kivity wrote: > 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. > 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(). > (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 -- 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
