Re: [RFC/PATCH 0/16] Ops based MSI Implementation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> That being said, it looks like the hypervisor calls just setup
> the MSI config inside of the PCI host controller, you still have
> to do the PCI config space writes.  So in this regard it's not
> like RTAS.

Ok, between the spec and your email, I think I sort-of understand it :-)
(damn, the Sun spec is a bit obscure...). 

So basically, from a kernel MSI backend perspective, I think you would
mostly use the "raw" implementation and locally implement your own
vector allocation.

However, your vector space is per-bus (which is good), so you do need to
allocate linux virtual irqs and map them to the actual MSI vectors like
we do on powerpc.

I think Eric's framework would work for you. As long as you don't need
to do something special for MSI-X, which I don't think you do...

Of course, Michael's stuff would work too, though it needs some
additions as you probably need to use config space (or MSI-X MMIO) for
masking & unmasking which we haven't implemented yet.

You are probably better off starting from Eric's stuff with his latest
patches I suppose...

At this point, I feel like Eric and use will not find a common ground,
which leaves us to those options:

 - Just give up and keep our current powerpc hooks at the toplevel. That
is, powerpc does it's own pci_enable_msi/x etc... (we need to fix those
hooks a bit but basically that's the idea). Internally, those go through
function pointers on which the RTAS implementation hooks directly, and
for non-RTAS powerpc archs, those point back to Eric's code which is
useable for these. In addition, I still want to have Eric's two "arch"
callbacks be themselves ops derived from the PCI device but that too can
be done in arch specific ways.

 - Give up in a different way and on powerpc, use Michael's
infrastructure and not use Eric's code at all (that means moving
Michael's stuff back to arch/powerpc which was Greg's original objection
to it).

 - Try to force our stuff in by implementing x86 completely (and Altix)
under Michael's infrastructure and then try to convince
Andrew/Greg/Linus to take it. Fairly unlikely. We do have a somewhat
"gradual" approach to it which consist of having Michael's code at the
toplevel, Eric's code hooked in as if it was a hypervisor, and then
gradually "merge" the raw backend with the x86 code, but it doesn't seem
very sexy (to me neither).

The main problem that I see that prevents us from an approach where
either we fix Michael's code to please Eric or change Eric's code to fit
our needs is that the way Eric code is evolving (based on his latest
patches), it's moving into a direction that is fundamentally unuseable
for our RTAS backend.

So unless Eric agrees to change his mind on that issue, we simply cannot
find a common abstraction. Which means that the only way we'll ever be
able to implement RTAS is by having separate hooks above Eric's code.

Ben.