public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yang, Sheng" <sheng.yang@intel.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Avi Kivity <avi@qumranet.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [patch 3/3] KVM: PIT: fix injection logic and count
Date: Mon, 28 Jul 2008 13:56:59 +0800	[thread overview]
Message-ID: <200807281356.59646.sheng.yang@intel.com> (raw)
In-Reply-To: <20080726200349.277527367@localhost.localdomain>

Hi Marcelo

Thanks for your work! It finally reslove my problem on failing to ack 
some injected interrupts. :)

On Sunday 27 July 2008 04:01:01 Marcelo Tosatti wrote:
> The PIT injection logic is problematic under the following cases:
>
> 1) If there is a higher priority vector to be delivered by the time
> kvm_pit_timer_intr_post is invoked ps->inject_pending won't be set.
> This opens the possibility for missing many PIT event injections
> (say if guest executes hlt at this point).

IRQ ack is of course the better way.

But I am still confuse about why PIT event lost. If higher priority 
vector there, it would inject first, but finally PIT one should be 
injected and because PIT inject one interrupt after another had been 
injected, so no PIT interrupt should be ignored.

>
> 2) ps->inject_pending is racy with more than two vcpus. Since
> there's no locking around read/dec of pt->pending, two vcpu's can
> inject two interrupts for a single pt->pending count.
>
> Fix 1 by using an irq ack notifier: only reinject when the previous
> irq has been acked. Fix 2 with appropriate locking around
> manipulation of pending count and irq_ack by the injection / ack
> paths.
>
> Also, count_load_time should be set at the time the count is
> reloaded, not when the interrupt is injected (BTW, LAPIC uses the
> same apparently broken scheme, could someone explain what was the
> reasoning behind that? kvm_apic_timer_intr_post).

PIT did so because we don't know how long we should wait for interrupt 
injection, so that point is nearer the real injection point. I think 
lapic have the similar reason.

I think keep timer_intr_post() for time update is reasonable.

--
regards
Yang, Sheng

  reply	other threads:[~2008-07-28  5:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-26 20:00 [patch 0/3] fix PIT injection Marcelo Tosatti
2008-07-26 20:00 ` [patch 1/3] KVM: Add irq ack notifier list Marcelo Tosatti
2008-07-26 20:01 ` [patch 2/3] KVM: irq ack notification Marcelo Tosatti
2008-07-26 20:01 ` [patch 3/3] KVM: PIT: fix injection logic and count Marcelo Tosatti
2008-07-28  5:56   ` Yang, Sheng [this message]
2008-07-29 14:29     ` Marcelo Tosatti
2008-07-29 12:55   ` Avi Kivity
2008-07-29 14:42     ` Marcelo Tosatti
2008-08-12 15:35   ` David S. Ahern
2008-07-28  4:31 ` [patch 0/3] fix PIT injection David S. Ahern
2008-07-29 12:50 ` Avi Kivity
2008-07-29 21:50 ` Dor Laor
2008-07-30 14:15   ` Marcelo Tosatti
2008-07-30 14:56     ` Sheng Yang
2008-07-30 21:48     ` Dor Laor

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=200807281356.59646.sheng.yang@intel.com \
    --to=sheng.yang@intel.com \
    --cc=avi@qumranet.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox