Re: [PATCH 5/5] powerpc: using reset hcall when kvm,has-reset

[Scott Wood <scottwood@freescale.com>]

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