From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: domU and dom0 hung with Xen console interrupt binding showing in-flight=1, (---M) Date: Wed, 18 Aug 2010 10:40:39 +0100 Message-ID: References: <4C6BBA480200007800010949@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C6BBA480200007800010949@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Bruce Edge Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 18/08/2010 09:47, "Jan Beulich" 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