From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Re: Xen crash on dom0 shutdown Date: Wed, 24 Sep 2008 10:13:00 +0100 Message-ID: References: <48DA1D83.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48DA1D83.76E4.0078.0@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 Cc: Yunhong Jiang , Haitao Shan , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 24/9/08 09:59, "Jan Beulich" wrote: >> Well, this hypercall doesn't do pirq_guest_unbind() on IO-APIC-routed >> interrupts either, so I think the problem is wider ranging than just MSI >> interrupts. Consider unmap_irq() followed by pirq_guest_unbind() later. >> We'll BUG_ON(vector == 0) in the latter function. Looks a bit of a mess to >> me. I would say that if there are bindings remaining we should re-direct the >> event-channel to a 'no-op' pirq (e.g., -1) and indeed call >> pirq_guest_unbind() or similar. > > How about this one? It doesn't exactly follow the path you suggested, > i.e. doesn't mess with event channels, but rather marks the > irq<->vector mapping as invalid, allowing only a subsequent event > channel unbind (i.e. close) to recover from that state (which seems > better in terms of requiring proper discipline in the guest, as it > prevents re-using the irq or vector without properly cleaning up). Yeah, this is the kind of thing I had in mind. I will work on this a bit more (e.g., need to synchronise on d->evtchn_lock to avoid racing EVTCHNOP_bind_pirq; also I'm afraid about leaking MSI vectors on domain destruction). Thanks. -- Keir