WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: odd IRQ behavior
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Fri, 27 Feb 2009 10:55:26 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Fri, 27 Feb 2009 10:55:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5CDBA65.3795%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4F65016F6CB04E49BFFA15D4F7B798D98D4BA47D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5CDBA65.3795%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmYft/BQyNL3H4qSR26RJ7HKdFeNQAD2HZgAAwLpTwACmr6QAACeLwBAAaMmvA=
Thread-topic: [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

<Prev in Thread] Current Thread [Next in Thread>