Re: [PATCHv2 2/9] KVM: Expose a version 2 architectural PMU to a guests

[Avi Kivity <avi@redhat.com>]

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