On 16.07.2013, at 00:23, Scott Wood wrote:
> 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.
Imagine we're running on KVM with this reset hcall support. Now if the guest has CONFIG_EPAPR_PARAVIRT enabled but CONFIG_KVM_GUEST disabled, we would patch the callback, but kvm_hypercall0() would be implemented as a nop.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
