>>> So.. is this change in the device_reset() signature really necessary? >>> Even if there are compelling reasons to handle warm reset in the new >>> API, that doesn't been you need to change device_reset() itself from >>> its established meaning of a cold (i.e. as per power cycle) reset. >>> Warm resets are generally called in rather more specific circumstances >>> (often under guest software direction) so it seems likely that users >>> would want to engage with the new reset API directly. Or we could >>> just create a device_warm_reset() wrapper. That would also avoid the >>> bare boolean parameter, which is not great for readability (you have >>> to look up the signature to have any idea what it means). >> >> I've added device_reset_cold/warm wrapper functions to avoid having to >> pass the boolean parameter. it seems I forgot to use them in qdev.c >> I suppose, like you said, we could live with >> + no function with the boolean parameter >> + device_reset doing cold reset >> + device_reset_warm (or device_warm_reset) for the warm version > > Ok, good. > > I'm afraid the whole series still makes me pretty uncomfortable, > though, since the whole "warm reset" concept still seems way to vague > to me.
Isn't the reset after the CAS negotiation sequence between the hypervisor and the pseries machine some sort of warm reset driven by SW ? C.
