[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/4] CPUIDLE: Avoid remnant LAPIC timerintr while force hpetbroadcast

  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 11 Sep 2008 12:06:55 +0100
  • Cc:
  • Delivery-date: Thu, 11 Sep 2008 04:07:51 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckSVfqaFjPrXqrARTKdgjxn6iTeJQA2DOERAAhrdiAAKqlasQAAe3QgAACEQPQ=
  • Thread-topic: [Xen-devel] [PATCH 2/4] CPUIDLE: Avoid remnant LAPIC timerintr while force hpetbroadcast

On 11/9/08 11:59, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

>> Also, in your patch, you unmask LVTT after reprogramming the
>> LAPIC counter.
>> Isn't there a race where the LAPIC timer generates an
>> interrupt event before
>> you unmask the LVTT and hence you lose the interrupt (since I
>> assume the
>> LAPIC interrupt is basically an internal one-shot signal which
>> does not get
>> latched in any way)? So you'd probably need to reprogram_timer(0), then
>> enable the timer, then reprogram_timer(<actual value>).
> You're correct. It will be fixed.

Thanks. I'm not sure whether the reprogram_timer(0) before re-enabling is
really required. It looks like Linux doesn't do similar (although if course
it does re-programming after re-enabling to avoid the above race).

I suppose repogram_timer(0) is cheap so you might choose to do it anyway.
It's up to you...

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.