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


[Xen-devel] bogus HPET initialization order on x86

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] bogus HPET initialization order on x86
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 09 Mar 2011 14:45:01 +0000
Delivery-date: Wed, 09 Mar 2011 06:48:32 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>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.

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

Thanks, Jan

Xen-devel mailing list