|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] RE: odd IRQ behavior
> 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).
Joe
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|