[PATCH 5/19] powerpc: add IRQ remapping hook

[Akira Iguchi]

Paul-san, Ben-san,

> On Thu, 2006-12-14 at 11:27 +0900, Ishizaki Kou wrote:
> > This patch adds irq remapping hook. On interrupt mechanism on Beat,
> > when an irq outlet who has an id which is formerly used is created,
> > remapping the irq is required.
> 
> Today paulus asked me what that was for and I must admit that despite
> your earlier explanations, I was a bit at a loss justifying it.
> 
> Can you explain us again the exact cicrumstances in which this is
> necessary ? It seems to us that if an interrupt outlet<->plug linkage is
> removed in the hypervisor itself, it should be also removed in linux
> using irq_dispose_mapping().
> 
> What are the cases where the HV might require a linkage to be
> re-established by that remap function that the kernel couldn't have done
> the cleanup itself beforehand ?

Okay, I'll try to explain.

Beat has two IDs to handle interrupts and events. IRQ outlets represent
interrupt sources, and IRQ plugs bind IRQ outlet to Guest OS.
So you have to "bind" IRQ plugs and IRQ outlets to receive interrupts.

Because of our design, you can assign and deassign any IRQ outlet to
a Guest OS even if the Guest OS uses the IRQ outlet without any notice
to the Guest OS. If the IRQ outlet is deassigned, bound IRQ plugs will
be also destroyed.

So, following scenario will be occur:
  1. Construct an IRQ outlet.
  2. Map it into IRQ plug by calling irq_create_mapping()
  3. Destruct the IRQ outlet.
  4. Forget to call irq_displose_mapping() because GuestOS is not
     notified.
  5. Reconstruct an IRQ outlet.
  6. If port number got at 1. and 5. are same, irq_create_mapping()
     (withour remapping patch) will reject binding between VIRQ and
     IRQ outlet, so IRQ plug is not constructed and connected to the
     IRQ outlet.

It can be occured with event receive port (sort of IRQ outlet).
Because I have no confidence that the "event receive port" users call
surely irq_dispose_mapping() whenever they destruct any event
receive port, I think interrupt-handling subsystem should overcome
this troublesome situation.

Best regards,
Akira Iguchi
Toshiba