On 07/15/2013 03:55:08 PM, Alexander Graf wrote:
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.
Oh, I misread "guest kernel" as "host kernel". :-P
Still, I'm not sure what sort of error you're thinking of. If the
guest didn't support the hcall mechanism we would have returned from
the function by that point. In fact, seeing kvm,has-reset on a
different hypervisor ought to mean that that hypervisor is emulating
KVM in this particular respect.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
