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" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
