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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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.

 -- Keir



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