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?
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.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
