> Am 21.05.2014 um 02:23 schrieb Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>: > > On Tue, 2014-05-20 at 22:39 +1000, Gavin Shan wrote: >>>> Yeah. How about this? :-) >>>> >>>> - Move eeh-vfio.c to drivers/vfio/pci/ >>>> - From eeh-vfio.c, dereference arch/powerpc/kernel/eeh.c::eeh_ops, which >>>> is arch/powerpc/plaforms/powernv/eeh-powernv.c::powernv_eeh_ops. Call >>> >>> Hrm, I think it'd be nicer to just export individual functions that >>> do thing you want to do from eeh.c. >> >> Ok. Got it. Thanks for your comments :) > > The interesting thing with this approach is that VFIO per-se can work > with EEH RTAS backend too in the host. > > 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. > > That is, vfio-eeh uses "generic" exported EEH APIs from the EEH core > that will work on both powernv and RTAS backends. > > 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 have a common code path for error handling. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
