[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



CC the author Wei Gang 

Regards
Ke

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Thursday, March 10, 2011 12:12 AM
> To: Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Yu, Ke
> Subject: Re: [Xen-devel] bogus HPET initialization order on x86
> 
> On 09/03/2011 14:45, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> 
> >> 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 appreciated.
> 
> Only someone at Intel could answer these questions. Cc'ing Yu Ke, who seems
> most involved in this aspect.
> 
>  -- Keir
> 
> > Thanks, Jan
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.