[Xen-devel] odd IRQ behavior

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

Sometime after c/s 19133 (I tried bisecting but there were some indeterminate 
results), during a shutdown/reboot in the tboot routines when it creates the 
1:1 mapping for itself, the map_pages_to_xen() call ends up in 
alloc_domheap_pages() where it triggers the assertion 'ASSERT(!in_irq());'.  In 
addition, and even stranger, is that when resuming from S3 is generates another 
assertion, 'BUG_ON(unlikely(in_irq()));' in invalidate_shadow_ldt().  From some 
debugging, the first assertion on entry is because the irq_count is 1 and the 
second is because it's -1.

Adding a irq_exit() before map_pages_to_xen() fixes the first assertion and 
causes the second, which is then fixed by irq_enter() on resume.

But why are these necessary?  Even if we say that something has caused the 
irq_count to go positive before shutdown (but what-it wasn't like this before 
pulling a more recent tree), the irq_exit() that gets rid of the assertion 
means that the count has gone to 0-so why is it negative on resume?

Joe


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