From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Re: [PATCH]: Really disable pirq's Date: Thu, 15 Nov 2007 09:10:49 -0500 Message-ID: <473C5369.7010209@redhat.com> References: <473B4840.4080502@redhat.com> <391BF3CDD2DC0848B40ACB72FA97AD590271FC38@pdsmsx413.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <391BF3CDD2DC0848B40ACB72FA97AD590271FC38@pdsmsx413.ccr.corp.intel.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: "Jiang, Yunhong" Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Jiang, Yunhong wrote: > Not sure if the change is a bit over-kill, since enable_pirq is has void > return type, while startup_pirq is "int" return type, with possibility > to fail. Thanks for looking! This is true, startup_pirq() *could* fail; but if you notice in the code, it doesn't actually have anything but a "return 0", so it doesn't report errors currently anyway. > > For example, in following situation, the startup_pirq may fail : 1) when > startup_pirq again, fail to get free port, 2) if another domain try to > bind the pirq with BIND_PIRQ_WILL_SHARE cleared (like to probing, will > it happen?) between the shutdown_pirq/startup_pirq sequence. Yes, you are right, this can happen if another domain is probing. However, I'm not sure that it is any different from when you are calling ->startup() for the first time; you will just fail to get the event channel. Without introducing another event channel op (which seems like a LOT of overkill), I'm not aware of another way of asking the HV to mask out that IRQ on the IOAPIC. Chris Lalancette