All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [patch 4/8] KVM: x86: replace hrtimer based timer emulation
Date: Wed, 8 Jul 2009 12:42:52 -0300	[thread overview]
Message-ID: <20090708154252.GA6364@amt.cnet> (raw)
In-Reply-To: <20090708133956.GP28046@redhat.com>

On Wed, Jul 08, 2009 at 04:39:56PM +0300, Gleb Natapov wrote:
> On Wed, Jul 08, 2009 at 10:17:21AM -0300, Marcelo Tosatti wrote:
> > On Wed, Jul 08, 2009 at 03:58:19PM +0300, Gleb Natapov wrote:
> > > Excellent patch series.
> > > 
> > > On Sun, Jul 05, 2009 at 10:55:15PM -0300, Marcelo Tosatti wrote:
> > > >  int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
> > > >  {
> > > > -	int ret;
> > > > +	ktime_t now, expires;
> > > >  
> > > > -	ret = pit_has_pending_timer(vcpu);
> > > > -	ret |= apic_has_pending_timer(vcpu);
> > > > +	expires = kvm_vcpu_next_timer_event(vcpu);
> > > > +	now = ktime_get();
> > > > +	if (expires.tv64 <= now.tv64) {
> > > > +		if (kvm_arch_interrupt_allowed(vcpu))
> > > > +			set_bit(KVM_REQ_UNHALT, &vcpu->requests);
> > > You shouldn't unhalt vcpu here. Not every timer event will generate
> > > interrupt (vector can be masked in pic/ioapic)
> > 
> > Yeah. Note however that kvm_vcpu_next_timer_event only returns the
> > expiration time for events that have been acked (for timers that have
> > had events injected, but not acked it returns KTIME_MAX).
> > 
> > So, the code above will set one spurious unhalt if:
> > 
> > - inject timer irq
> > - guest acks irq
> > - guest mask irq
> > - unhalt (once)
> > 
> > I had a "kvm_timer_mask" callback before (along with the attached
> > patch), but decided to keep it simpler using the ack trick above.
> > 
> > I suppose one spurious unhalt is harmless, or is it a correctness issue?
> > 
> This is correctness issue. We should be as close to real CPU as
> possible. This will save us may hours of debugging later :)

Hum, fine. Will update the kvm_timer_mask patch below and let you know.

> > > or timer event can generate NMI instead of interrupt.
> > 
> > In the NMI case it should not unhalt the processor?
> Why? It should. It should jump to NMI handler.

I meant unhalt as in KVM_REQ_UNHALT so vcpu_enter_guest runs.

What did you mention about ISR/IRR again?


  reply	other threads:[~2009-07-08 15:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-06  1:55 [patch 0/8] RFC: in-kernel timer emulation changes Marcelo Tosatti
2009-07-06  1:55 ` [patch 1/8] KVM: timer interface unification Marcelo Tosatti
2009-07-08 13:33   ` Avi Kivity
2009-07-06  1:55 ` [patch 2/8] KVM: move lapic timer ack to EOI handler Marcelo Tosatti
2009-07-06  1:55 ` [patch 3/8] KVM: x86: per-vcpu timer list Marcelo Tosatti
2009-07-06  1:55 ` [patch 4/8] KVM: x86: replace hrtimer based timer emulation Marcelo Tosatti
2009-07-08 12:58   ` Gleb Natapov
2009-07-08 13:17     ` Marcelo Tosatti
2009-07-08 13:39       ` Gleb Natapov
2009-07-08 15:42         ` Marcelo Tosatti [this message]
2009-07-08 16:13           ` Gleb Natapov
2009-07-08 16:29       ` Gleb Natapov
2009-07-08 16:37         ` Marcelo Tosatti
2009-07-08 16:40           ` Gleb Natapov
2009-07-08 16:47             ` Marcelo Tosatti
2009-07-08 13:41   ` Avi Kivity
2009-07-08 16:24     ` Marcelo Tosatti
2009-07-08 16:36       ` Avi Kivity
2009-07-06  1:55 ` [patch 5/8] KVM: timer: honor noreinject tunable Marcelo Tosatti
2009-07-06  1:55 ` [patch 6/8] KVM: timer: optimize next_timer_event and vcpu_arm_exit Marcelo Tosatti
2009-07-06  1:55 ` [patch 7/8] KVM: PIT: removed unused code Marcelo Tosatti
2009-07-06  1:55 ` [patch 8/8] kvmctl: time testcase Marcelo Tosatti
2009-07-08 13:43 ` [patch 0/8] RFC: in-kernel timer emulation changes Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090708154252.GA6364@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.