RE: [Xen-devel] RE: odd IRQ behavior

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Cihula, Joseph
>Sent: Saturday, February 28, 2009 2:55 AM
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: Friday, February 27, 2009 7:42 AM
>>
>> On 27/02/2009 14:35, "Cihula, Joseph" 
><joseph.cihula@xxxxxxxxx> wrote:
>>
>> >> Please provide some backtraces.
>> >>
>> >>  -- Keir
>> >
>> > Trace of assertion at shutdown entry:
>>
>> Okay, the ASSERT(!in_irq()) crash on shutdown is due to 
>having IPIed to the
>> BP to make it drive the shutdown. Hence the BP is actually 
>in IRQ context.
>> If you then zero the IRQ counter, it will get decremented on 
>exit from the
>> shutdown code (and the IPI interrupt) on S3 resume... Except 
>I'm confused by
>> this because machine_restart() is not used for S3 suspend/resume. So
>> actually I'm not sure how you end up in IRQ context on S3 
>suspend, and you
>> didn't send a backtrace of that situation. To get to the BP 
>on S3 suspend we
>> use continue_hypercall_on_cpu(), which does not leave us in 
>IRQ context.
>>
>> For the check_lock() assertion, either do not local_irq_disable() in
>> tboot_shutdown() (is that needed?) or perhaps even better 
>(solves all the
>> crashes you've seen) why not disable paging before jumping 
>into tboot and
>> hence avoid needing map_pages_to_xen()? I can't see why 
>tboot would care to
>> run on our random pagetables, and implementing a stub to 
>jump into / out of
>> non-paged mode would be very easy. I can explain more how to 
>do this if this
>> is a suitable solution. Another alternative would be to map 
>tboot pages
>> during boot and leave them mapped forever after. That also 
>would avoid these
>> map_pages_to_xen() during S3/shutdown issues, and I suppose 
>is easier than
>> implementing a return-to-no-paging stub.
>
>On S3, we also need to create integrity measurements for the 
>xenheap and domheap, which require mapping pages.  So I don't 
>think that either moving the 1:1 mapping early or the disable 
>paging would solve the problem (it would just shift it).
>
>I think that I did find a way to avoid the reboot spinlock 
>BUG_ON by using spin_debug_{disable/enable}().  S3 still isn't 
>working, but I haven't been able to track down why yet 
>(unfortunately, serial output stops before it fails).
>

Just be caution that current Xen upstream has several S3 bugs
which was fixed by Guanqun but not checked in yet. Maybe you
can have a try by http://markmail.org/thread/fkcowjzdbqq3qbjp
to avoid hunting same issues.

Thanks
Kevin

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