On Wed, Jun 12, 2013 at 02:19:25PM +1000, Benjamin Herrenschmidt wrote: >On Wed, 2013-06-12 at 11:32 +0800, Gavin Shan wrote: > >> >Same comments about "state" which is really "delay" and is probably >> >not necessary at all ... >> > >> >> We need the "delay" in future to support PowerKVM guest. If the >> specified PE is being reset, we rely on the delay to hold the >> powerkvm guest for a while until the PE reset is done. > >Do we ? Can't we just rely on "temp unavailble" result and wait 1s when >that happens (then try again) ? > >IE, A delay associated with a state doesn't make that much sense >semantically speaking. With a state *transition* maybe but this isn't >what this function is about... >
Sorry, Ben. I should have clarified more clearly: Basically, the EEH core is going to be shared by: powernv, pseries on top of powernv or phyp. While running pseries on top of phyp, we're getting PE state through RTAS call "ibm,read-slot-reset-state2" and desired delay returned from f/w for temporary unavailable PE. In the future, the function ioda_eeh_get_state() will be called directly to emulate the RTAS call for guest running on top of PowerNV. So the answer is we can do it by makeing the assumption that f/w won't return valid delay and we're going to use default value (1 second) for guest on powernv or phyp, or we keep the delay here. Thanks, Gavin _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
