On 15.07.2013, at 22:52, Scott Wood wrote: > On 07/15/2013 03:28:46 PM, Alexander Graf wrote: >> On 15.07.2013, at 20:21, Scott Wood wrote: >> > On 07/15/2013 10:16:41 AM, Bhushan Bharat-R65777 wrote: >> >> > >>> + printk("error: system reset returned with error %ld\n", ret); >> >> > >> >> >> > >> So we should fall back to the normal reset handler here. >> >> > > >> >> > > Do you mean return normally from here, no BUG() etc? >> >> > >> >> > If we guard the patching against everything, we can treat a broken >> >> > hcall as BUG. >> >> > However, if we don't we want to fall back to the normal guts based >> >> > reset. >> >> Will let Scott comment on this? >> >> But ppc_md.restart can point to only one handler and during paravirt >> >> patching we changed this to new handler. So we cannot jump back to guts >> >> type handler >> > >> > I don't think it's worth implementing a fall-back scheme -- if KVM >> > advertises that the reset hcall exists, then it had better exist. >> If we also check for kvm_para_available() I agree. Otherwise QEMU might >> advertise the reset hcall, but the guest kernel may not implement KVM >> hypercalls. In that case the device tree check will succeed, but the actual >> hypercall will not. > > Wouldn't that be a bug in QEMU? Or in KVM for exposing the hcall capability > without implementing them?
No, because it would be the guest that doesn't know how to handle kvm hypercalls. > Not that I have anything against checking kvm_para_available()... though > that (or its functional equivalent that returns a pointer to the node) should > really be a prerequisite for even being able to interpret KVM-specific > properties in the hypervisor node. That's my point :). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html