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().
Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel