On Tue, 2014-05-27 at 14:37 -0600, Alex Williamson wrote: > > The usual way is the driver asks for one or the other, this plumbs back > > into the guest EEH code which itself plumbs into the PCIe error recovery > > framework in Linux. > > So magic? Yes. The driver is expected to more or less knows what kind of reset it wants for its device. Ideally hot reset is sufficient but some drivers knows that the device they drive is crappy enough that it mostly ignores hot reset and really needs a PERST for example... Also we have other reasons to expose those interfaces outside of EEH. For example, some drivers might want to specifically trigger a PERST after a microcode update. IE. There are path outside of EEH error recovery where drivers in the guest might want to trigger a reset to the device and they have control under some circumstances on which kind of reset they are doing (and the guest Linux does have different code path to do a hot reset vs. a fundamental reset). So we need to expose that distinction to be able to honor the guest decision. Cheers, Ben. -- 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
