From: Akira Iguchi <akira2.iguchi@toshiba.co.jp>
To: paulus@samba.org, benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 5/19] powerpc: add IRQ remapping hook
Date: Fri, 15 Dec 2006 13:59:40 +0900 [thread overview]
Message-ID: <200612150458.kBF4w8KC028184@toshiba.co.jp> (raw)
In-Reply-To: <1166072316.11914.284.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2006-12-15 4:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-14 2:27 [PATCH 5/19] powerpc: add IRQ remapping hook Ishizaki Kou
2006-12-14 4:58 ` Benjamin Herrenschmidt
2006-12-15 4:59 ` Akira Iguchi [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-01-12 0:58 Ishizaki Kou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200612150458.kBF4w8KC028184@toshiba.co.jp \
--to=akira2.iguchi@toshiba.co.jp \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox