On Fri, 2014-05-23 at 14:37 +1000, Gavin Shan wrote: > >There's no notification, the user needs to observe the return value an > >poll? Should we be enabling an eventfd to notify the user of the state > >change? > > > > Yes. The user needs to monitor the return value. we should have one notification, > but it's for later as we discussed :-) ../.. > >How does the guest learn about the error? Does it need to? > > When guest detects 0xFF's from reading PCI config space or IO, it's going > check the device (PE) state. If the device (PE) has been put into frozen > state, the recovery will be started. Quick recap for Alex W (we discussed that with Alex G). While a notification looks like a worthwhile addition in the long run, it is not sufficient and not used today and I prefer that we keep that as something to add later for those two main reasons: - First, the kernel itself isn't always notified. For example, if we implement on top of an RTAS backend (PR KVM under pHyp) or if we are on top of PowerNV but the error is a PHB "fence" (the entire PCI Host bridge gets fenced out in hardware due to an internal error), then we get no notification. Only polling of the hardware or firmware will tell us. Since we don't want to have a polling timer in the kernel, that means that the userspace client of VFIO (or alternatively the KVM guest) is the one that polls. - Second, this is how our primary user expects it: The primary (and only initial) user of this will be qemu/KVM for PAPR guests and they don't have a notification mechanism. Instead they query the EEH state after detecting an all 1's return from MMIO or config space. This is how PAPR specifies it so we are just implementing the spec here :-) Because of these, I think we shouldn't worry too much about notification at this stage. 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
