On Fri, Mar 10, 2006 at 09:30:38AM -0600, Hollis Blanchard wrote:
> 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.
Not that you have a choice on PPC970, but there's a drawback to this: If
you let all interrupts be delivered directly to the domain, then it can
hold the PIC "hostage" by disabling the delivery (keeping MSR_EE off),
causing interrupts to other domains to be delayed.
Some PPC processors have a feature called "mediated external interrupts",
where they will be delivered to the hypervisor instead, and if the domain
can't service it then (MSR_EE off), the HV can request to be notified
when the domain can take it. The extra code path for re-delivering to a
domain can be made short.
rHype has some support for this already, but it's unclear which hardware
has it. If I had to guess I would say at least Cell, since those parts
of rhype are ripped out in the sources but some of the infrastructure
is still in there.
I'm just mentioning this in case the IA64 guys have something like
mediated interrupts as an option, they might want to go with that for
the fairness/latency reasons.
-Olof
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home