Am 21.05.2014 um 02:23 schrieb Benjamin Herrenschmidt <benh@kernel.crashin=

g.org>:

=20
On Tue, 2014-05-20 at 22:39 +1000, Gavin Shan wrote:

quoted

quoted

quoted

Yeah. How about this? :-)
=20
- Move eeh-vfio.c to drivers/vfio/pci/
- =46rom eeh-vfio.c, dereference arch/powerpc/kernel/eeh.c::eeh_ops, wh=

ich

quoted

quoted

quoted

 is arch/powerpc/plaforms/powernv/eeh-powernv.c::powernv_eeh_ops. Call

=20
Hrm, I think it'd be nicer to just export individual functions that
do thing you want to do from eeh.c.

=20
Ok. Got it. Thanks for your comments :)

=20
The interesting thing with this approach is that VFIO per-se can work
with EEH RTAS backend too in the host.
=20
IE, with PR KVM for example or with non-KVM uses of VFIO, it would be
possible to use a device in a user process and exploit EEH even when
running under a PAPR hypervisor.
=20
That is, vfio-eeh uses "generic" exported EEH APIs from the EEH core
that will work on both powernv and RTAS backends.
=20
Note to Alex: This definitely kills the notifier idea for now though,
at least as a first class citizen of the design. We can add it as an
optional optimization on top later.

I don't think it does. The notifier would just get triggered on config space=
 read failures for example :). It's really just an aid for the vfio user to h=
ave a common code path for error handling.


Alex