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