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

[Gleb Natapov <gleb@redhat.com>]

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.