This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] bogus HPET initialization order on x86

To: Jan Beulich <JBeulich@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] bogus HPET initialization order on x86
From: "Wei, Gang" <gang.wei@xxxxxxxxx>
Date: Thu, 10 Mar 2011 11:35:41 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Wed, 09 Mar 2011 19:36:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D77A43A0200007800035980@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D77A07D020000780003593A@xxxxxxxxxxxxxxxxxx> <4D77A43A0200007800035980@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcveaujjAXbAAZRxSgqfFM0yqWtzagAXIsPQ
Thread-topic: [Xen-devel] bogus HPET initialization order on x86
Jan Beulich wrote on 2011-03-09:
>>> From looking at the code I cannot deduce why it wouldn't be
>>> possible
>> for hpet_interrupt_handler() or hpet_legacy_irq_tick() to be called
>> while hpet_broadcast_init() is still executing. If that's indeed
>> possible, then the setting of .event_handler clearly has to happen
>> *after* initializing the channel's spinlock and rwlock.

First of all, pulling the code initializing the channel's spinlock & rwlock 
before the setting of .event_handler should be a cleaner way anyway.

>> Further, with the channel getting enabled (down the
>> hpet_fsb_cap_lookup() call tree) before hpet_events[] gets fully
>> initialized, I'd also think it should be possible to hit the
>> spurious warning in hpet_interrupt_handler() just because of
>> improper initialization order.
>> If that's all impossible in practice, adding some meaningful
>> comments to the code to describe why this is so would be much appreciated.

For normal booting case, hpet interrupts should not come before dom0 start 
booting and pass ACPI tables to hypervisor, so that's impossible in practice in 
this case.

For S3 resume case, the hpet_broadcast_init() is called in 
device_power_up()->time_resume()->disable_pit_irq(), when the irq was disabled 
and all non-boot cpus not enabled. So that's also impossible.

Do I miss any other cases? If not, I will cook a patch to add the required 
comments along with pulling spinlock/rwlock initialization before 
.event_handler settings.

> Also, what's the point of decrementing the per-CPU irq_count in
> hpet_legacy_irq_tick()?

The per-CPU irq_count are used for calculate the total irq number excluding 
hpet irqs in a past period to give a estimation of IO frequence. The hpet irq 
was counted in do_IRQ, so need to reduce it while handling it. You can see 
another one in hpet_interrupt_handler().


Xen-devel mailing list