[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EB7F58D.6080102@redhat.com>
Date: Mon, 07 Nov 2011 17:13:17 +0200
From: Avi Kivity <avi@...hat.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: Gleb Natapov <gleb@...hat.com>, kvm@...r.kernel.org,
mtosatti@...hat.com, linux-kernel@...r.kernel.org, mingo@...e.hu,
acme@...stprotocols.net
Subject: Re: [PATCHv2 2/9] KVM: Expose a version 2 architectural PMU to a
guests
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists