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] domU and dom0 hung with Xen console interrupt binding sh

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Bruce Edge <bruce.edge@xxxxxxxxx>
Subject: Re: [Xen-devel] domU and dom0 hung with Xen console interrupt binding showing in-flight=1, (---M)
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 18 Aug 2010 10:40:39 +0100
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 18 Aug 2010 02:41:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C6BBA480200007800010949@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs+se/Dk4axAR7ZSSa1s6lx3uUEIQAB3rt7
Thread-topic: [Xen-devel] domU and dom0 hung with Xen console interrupt binding showing in-flight=1, (---M)
User-agent: Microsoft-Entourage/12.26.0.100708
On 18/08/2010 09:47, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> Yes, that was what I was trying to hint at, but I wasn't sure whether
> calling ->end() here has any unintended side effects and/or requires
> any extra care (like preventing a subsequent guest initiated EOI to
> call ->end() again).

Oh you can't naively call ->end() from the time-out handler. You would need
to do something like this in irq_guest_eoi_timer_fn:
 spin_lock(&desc->lock);
 if ( (desc->status & IRQ_GUEST) &&
      (action->ack_type == ACKTYPE_EOI) ) {
    cpu_eoi_map = action->cpu_eoi_map;
    spin_unlock(&desc->lock);
    on_selected_cpus(&cpu_eoi_map, set_eoi_ready, desc, 0);
    spin_lock(&desc->lock);
 }
 _irq_guest_eoi(desc);
 spin_unlock(&desc->lock);

I don't think the IRQ_GUEST_EOI_PENDING flag or any of that stuff is needed
for the ACKTYPE_EOI case. I'd make the handling of that, calling of
->disable/->enable and so on, dependent on ACKTYPE_NONE.

> While looking at this I came across another thing I don't understand:
> __pirq_guest_eoi(), for the ACKTYPE_EOI case, calls __set_eoi_ready()
> in a cpu_test_and_clear() conditional, but __set_eoi_ready() bails
> out if it finds !cpu_test_and_clear() on the same bitmap - what's the
> point of calling __set_eoi_ready() here then (or what am I missing)?

__pirq_guest_eoi() acts on a private on-stack copy of cpu_eoi_map. This is
because on_selected_cpus() cannot be called with desc->lock held. But as
soon as desc->lock is released, the desc->action structure can be freed by
another CPU, so it would be invalid to reference action->cpu_eoi_map
directly after desc->lock is released.

 -- Keir



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