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

[Scott Wood <scottwood@freescale.com>]

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