From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: Re: APIC rework
Date: Tue, 17 Nov 2009 13:05:06 +0000
Message-ID: <C7285002.C27B%keir.fraser@eu.citrix.com>
References: <706158FABBBA044BAD4FE898A02E4BC201CD3205FF@pdsmsx503.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC201CD3205FF@pdsmsx503.ccr.corp.intel.com>
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: "Zhang, Xiantao" <xiantao.zhang@intel.com>, Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Xen-devel <xen-devel@lists.xensource.com>, "Han,
	Weidong" <weidong.han@intel.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
List-Id: xen-devel@lists.xenproject.org

On 17/11/2009 12:46, "Zhang, Xiantao" <xiantao.zhang@intel.com> wrote:

>> If Xen can set the interrupt triggering by itself, why would it ever
>> need dom0 to do it?  Couldn't it just preconfigure all the pins, and
>> then wait for dom0 to provide/request the pirq<->evtchn mapping?
> 
> After reviewing the logic, I think we can use DOMID_SELF to identify new dom0.
> In linux-2.6.18 dom0, only qemu uses this hypercall for device assginment, so
> map->domid shouldn't be dom0.  If old dom0/qemu with this hypercall, keeps the
> logic unchanged, and only change the logic for new dom0 when call into it.
> Attached the patch.

Don't like it (subtle semantic difference based on domid field is very odd
and could bite us later), and actually now I look closer I don't like the
original patch much either, if only because it does clearly change the
interface for MAP_PIRQ_TYPE_GSI by adding trigger/polarity flags (and not
documented or exported properly in the physdev.h header file).

I need to take a step back and work out what in fact you're trying to
achieve. I'm going to revert the original patch from xen-unstable. If such
an interface extension is really required, I think at least the new
interface should be a new subtype of MAP_PIRQ_TYPE_xxx, properly described
in the header file. But like I say, I don't know what the patch is even
really trying to do or overcome.

 -- Keir