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

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

> Look, I have no idea where all this resistence come from to abstract
> this stuff behind enough levels to support things like RTAS et al.
> properly.  Please stop it now.

Note that to be totally fair, in some aspects (mostly simplicity gained
from not handling the RTAS-type setup), Eric code is nicer than our
proposal.

What annoys me is that Eric wants to completely separate the handling of
RTAS-type via a separate abstraction than the "classic" case.

The main thing here is that with Eric code, the backend really only
cares about one interrupt at a time, via the alloc/free hook, and thus
can totally ignore wether it's an MSI or one of multiple MSI-X (or even
one of multiple MSIs if we ever support that).

Michael's code makes it a little bit less transparent... alloc() /
free() has to operate on a level that matches the HV interfaces, thus
are called for either a single MSI or a set of MSI-X, though we made
that interface nice enough so we really only deal with an array and a
count (with the count being 1 for a single MSI).

One thing we could do, is remove our enable/disable hooks. The
functionality can be kept into the core, as is with Eric's code,
provided we have a way for alloc/free to say "job done, nothing else
needed", via either a special result code or maybe an ops "member"
variable set to 1 statically in the definition of the RTAS ops.

Another thing is we still need to have the addr/data returned for the
non-RTAS case. Eric doesn't like the setup_msi_msg() callback through
the ops because it operates at a different layer than alloc/free. The
option there would have to have alloc/free return the setup infos and
store them in the msi data on platforms where that is useful.

At this point I don't really have a firm preference of either taking
Michael's code and changing it in some areas to please Eric or try to
evolve from Eric's code, though I do feel that the later would still
have strong resistance in the area where alloc/free are concerned, that
is the whole idea of allocating the whole set at once or per-MSI, the
later being unsuitable for RTAS-like implementations.

Ben.