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

[Xen-devel] Re: IRQs delivery.

To: Tristan Gingold <Tristan.Gingold@xxxxxxxx>
Subject: [Xen-devel] Re: IRQs delivery.
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Fri, 10 Mar 2006 09:30:38 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 10 Mar 2006 15:33:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200603101107.01234.Tristan.Gingold@xxxxxxxx>
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>
Organization: IBM Linux Technology Center
References: <200603101107.01234.Tristan.Gingold@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8.3
On Friday 10 March 2006 04:07, Tristan Gingold wrote:
> 
> How xen/ppc delivers interrupts ?

Ignoring hypervisors for a moment, the PPC model for external interrupts is 
this: the hardware resets the PC to a fixed entry point (0x500) and changes 
the MSR to put the processor into real (untranslated) mode. (The old PC and 
MSR are saved into a pair of supervisor-only registers, SRR0 and SRR1.) The 
exception handler is then responsible for querying the interrupt 
controller(s) to get the interrupt vector, and then call the appropriate 
driver.

The IBM Research hypervisor (rhype) virtualized the PIC, so that instead of 
querying hardware, the kernel makes an hcall to find the incoming vector. If 
the interrupt is not in fact for this domain, the hypervisor queues the 
interrupt for later and tells the current domain "nothing was pending after 
all". Note that in this model, interrupts are delivered by the hardware 
directly to the current domain without hypervisor involvement.

With Xen, the hypervisor simulates hardware delivering an interrupt (jumping 
to 0x500), and then the kernel looks at the event channel structures (instead 
of making an hcall) to figure out what happened.

Important note: in our current implementation, interrupts are always delivered 
by hardware to the hypervisor, and then we simulate the interrupt delivery to 
the domain. Because of the increased latency, it's possible that in the 
future we'll want to adopt a more rhypish model. However, since the 
hypervisor itself takes interrupts, we need to be able to simulate domain 
interrupt delivery anyways.

> on xen-ia64-devel, we are currently discussing on IRQ delivery.
> Xen/x86 delivers IRQs using the event channel.
> Xen/ia64 currently delivers IRQs using the virtualized hardware way.
> 
> Is there major drawbacks about not using event channel (from a XEN POV) ?

I'm not sure what "the virtualized hardware way" is. You probably need to 
virtualize the PIC *somehow*, and the Xen event channels are as good a way as 
any to do that. If IA64 already has an unrelated way of virtualizing the PIC 
(as PPC did with the rhype model), then you get to choose. If that's the 
case, I would recommend adopting the event channels to share more Xen code 
and design...

-- 
Hollis Blanchard
IBM Linux Technology Center

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