From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bastian Blank <waldi@debian.org>
Subject: Re: pvops-2.6.32 - Interrupt routing problem
Date: Sun, 21 Mar 2010 22:47:23 +0100
Message-ID: <20100321214723.GA29738@wavehammer.waldi.eu.org>
References: <EB8593BCECAB3D40A8248BE0B6400A38464169F7@shzsmsx502.ccr.corp.intel.com>
	<20100315101126.GA24650@wavehammer.waldi.eu.org>
	<EB8593BCECAB3D40A8248BE0B6400A38464AE52E@shzsmsx502.ccr.corp.intel.com>
	<20100315211459.GA9314@wavehammer.waldi.eu.org>
	<20100316013114.GD7622@phenom.dumpdata.com>
	<20100316081832.GA20502@wavehammer.waldi.eu.org>
	<20100316153216.GB28821@phenom.dumpdata.com>
	<20100316182053.GA2258@wavehammer.waldi.eu.org>
	<20100319113904.GA29200@wavehammer.waldi.eu.org>
	<20100319121341.GA30270@wavehammer.waldi.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <20100319121341.GA30270@wavehammer.waldi.eu.org>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir Fraser <keir.fraser@eu.citrix.com>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>
List-Id: xen-devel@lists.xenproject.org

On Fri, Mar 19, 2010 at 01:13:41PM +0100, Bastian Blank wrote:
> The real fix could be:
> - Allow the hypervisor to lock interrupts it uses. Zero would be in it by
>   default. The interrupt for the used serial interface would be added.
>   All other pins are free to be programmed by the kernel once.
> - Don't do register_gsi calls from the initial setup in the kernel if no
>   ACPI override is present, only setup the rest.

Okay, I think I found another problem. Currently the setup looks like
this:
- PHYSDEVOP_setup_gsi: set trigger and polarity, unmask pin
- PHYSDEVOP_map_pirq: map to pirq, set irq handler to guest

If an interrupt fires between this two calles, what happens?

Usually I would do the setup the other way around. This would also make
it possible to use the irq table to allow the kernel to only set IO-APIC
pins mapped to already properly registered interrupts.

Bastian

-- 
Change is the essential process of all existence.
		-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2