WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH, resend] replacement for noirqdebug hack

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH, resend] replacement for noirqdebug hack
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 2 Jun 2006 11:32:15 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Jun 2006 03:32:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <448028CD.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <448028CD.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 2 Jun 2006, at 11:02, Jan Beulich wrote:

Instead of re-establishing the noirqdebug hack earlier present in the i386 Linux code, communicate the information about whether a particular IRQ is shared across domains from hypervisor to kernel.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
This is gross for a few reasons. Firstly it adds Xen cruft to a file we 
don't currently modify, and the changes would never be mergable 
upstream. Plus I'd prefer a lighter weight solution for handling this 
x86 crufty corner case -- adding extra bitmaps to shared_info and 
updating bits on every IRQ delivery is overkill imo.
What I would suggest is change note_interrupt() to only increment 
irqs_unhandled if some new function spurious_irqs_ok(irq) returns 
false. We can then define that function as Xen-specific and extend 
physdev_irq_status_query to be able to determine if an irq is shared 
across guests. We can avoid frequent hypercalls by caching the shared 
status the first time it evaluates true (so sharedness is sticky; I'd 
assume we would rarely take the path that executes the hypercall if the 
irq is really not shared).
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel