|
xen-devel
RE: [Xen-devel] bogus HPET initialization order on x86
|
To: |
Jan Beulich <jbeulich@xxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] bogus HPET initialization order on x86 |
|
From: |
"Wei, Gang" <gang.wei@xxxxxxxxx> |
|
Date: |
Fri, 11 Mar 2011 10:43:33 +0800 |
|
Accept-language: |
zh-CN, en-US |
|
Acceptlanguage: |
zh-CN, en-US |
|
Cc: |
"keir.xen@xxxxxxxxx" <keir.xen@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx> |
|
Delivery-date: |
Thu, 10 Mar 2011 18:44:35 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4D7933EE020000780006C4B6@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: |
<4D7933EE020000780006C4B6@xxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AcvfYW9PHk0uNB1/S8S5HI34RaCREAAJgiHQ |
|
Thread-topic: |
[Xen-devel] bogus HPET initialization order on x86 |
Jan Beulich wrote on 2011-03-11:
>>>> "Wei, Gang" 03/10/11 4:36 AM >>> Jan Beulich wrote on 2011-03-09:
>>>> 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.
>
> The legacy code path gets called from the timer interrupt, so what
> would prevent this path being taken before Dom0 boots?
Oh, yes, you are right. The legacy code path may get called before PIT
interrupt being turned off. If we put the initialization of
legacy_hpet_event.event_handler at the end of hpet_broadcast_init(), things
should be ok. Further, it would be better if we could disable PIT interrupt
before calling hpet_broadcast_init(), and re-enable PIT interrupt only while
PIT broadcast is needed.
> The non-legacy interrupts also get fully set up before Dom0 boots - I
> don't think I saw anything that specifically enables these interrupts
> upon arrival of some ACPI data from Dom0.
The non-legacy interrupts will only come after some hpet channels was
programmed. Before hypervisor got ACPI data from Dom0 and be capable to enter
deep C states, hpet channels were not programmed.
>> 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.
>
> Yes, please, though I could also fold this in my bigger cleanup patch
> (properly separating init a resume paths) if I still didn't understand
> some aspect of it and this turns out a mere cleanup.
Oh, if you like, you can definitely include these change in your cleanup patch.
It is your finding. You deserve the credit. I can just help to review & ack.
Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home